Programadores Profissionais Escrevem Testes, Ponto Final.

O tópico já tem oito páginas. Acho que chega à 10. Por mais que minha mão coce para comentar lá eu não vou, simplesmente porque já tive problemas demais com o pessoal do Mentawai.

De qualquer forma sempre me preocupa a possibilidade de algum desenvolvedor ler o tópico e pensar “Poxa, se esses caras que fazem todos estes frameworks não usam testes por que eu vou usar?”.

Desenvolvedores profissionais escrevem testes. Simples assim.

Uma pessoa que não ganha milhões de dólares mas escreveu uma das obras mais clássicas deste ramo deixa bem claro em sua primeira aula que programar é gerenciar complexidade. Nós precisamos gerenciar complexidade o tempo todo, por isso criamos funções, objetos e tudo mais. Não adianta, mesmo Einstein teve que provar que suas fórmulas e execuções estavam corretas, que poderiam ser verificadas. Na faculdade aprende-se isso desde as cadeiras básicas (e o fato de ser esquecido como “coisa teórica inútil” me faz novamente perguntar sobre o valor do ensino formal).

Existe uma grande diferença entre fazer Test-Driven Development e testar. TDD é sobre modelagem de objetos e especificações, não sobre testes (tanto que Behaviour Driven Development está se consolidando como algo mais eficiente que TDD) apesar de que no final você acaba ganhando uma suíte de testes de graça.

É muito difícil achar um projeto open-source relevante que não tenha testes. Na verdade os projetos decentes só aceitam um relatório de bug ou um patch se vier acompanhando por um caso de testes. Imagine uma aplicação feita colaborativamente por diversas pessoas, como saber que o que eu acabei de fazer commit não vai quebrar o que você modificou ontem? Boas práticas de orientação a Objetos? Não se iludam, OO não foi feita para este tipo de verificação! Com boas práticas você consegue minimizar o impacto de mudanças diminuindo dependências mas você não vai ter certeza disso.

Eu sinceramente não sei que técnica é essa que faz programação defensiva evitar testes. Eu já li bastante sobre Orientação a Objetos e programação defensiva e não vi nada deste tipo, pelo menos não vindo de uma fonte com um mínimo de credibilidade. Um exemplo simples, imagine que o framework web imaginário Pagai possui um código parecido com este:


Acao acaoSendoExecutada = controladorPrincipal.acao(requisicao.acaoDesejada());

Simples, não? Agora imaginemos que o código do método acao(String) seja algo assim:


public Acao acao(String pathInvocado){
//verifica se acao possui o formato desejado, deve ter uma barra e deve ter dois itens separados por barra apenas
if((pathInvocado.indexOf("/") == -1) || (pathInvocado.split("/").size < 2)) throw new IllegalArgumentException("Path invocado ["+pathInvocado+"] nao possui o formato adequado (consulte a documentacao XYZ)");
//lógica...
}

Isso é programação defensiva: eu não estou aceitando o que me passam, eu verifico se é o que deveria e se for eu continuo, se não eu paro ali mesmo e deixo alguém tomar conta do problema, seja a classe em questão ou alguma outra mais acima.

Imagine que eu por engano commitei um código que utilize “” em vez de “/” nesta requisição. Se for numa parte central do código é bem possível que uns testezinhos peguem mas imagine que é utilizado apenas em um caso específico e que, por um acaso, eu baseei meu sistema de controle de jatinhos particulares 9meu chefe tem muitos jatinhos) nele. Quando eu fiz o comit não alertou. Quando eu fiz o build não alertou. Quando eu fiz meus testezinhos não alertou. Quando foi para a produção eu tive erro.

Ok, acontece. Programadores de qualquer tipo cometem erros. Eu vejo o problema muito rapidamente e o corrijo, temos uma versão beta em 15 minutos no ar, fantástico. Aí daqui há um mês outro programador comete o mesmo erro. Quando fizer o build não vai alertar. Quando fizer seus testezinhos não vai alertar. Quando for para a produção… Isso não é profissionalismo.

O que eu preciso é de uma suite de testes, unitários e de integração, que me digam que o sistema está incorreto já no processo de build, sem lançar jars beta, alfa ou gama.

Mas se tem um argumento nessa história toda que realmente me irrita é quando as pessoas dizem que “num mundo capitalizado não há tempo para testes” ou que “o cliente não quer saber como é feito, ele quer que funcione”. O cliente realmente não quer saber como funciona, ele quer que funcione. Mas ele também não vai querer saber que você alterou uma classe que usava barra para barra invertida e tudo parou de funcionar, ele quer que o problema não aconteça e se acontecer que seja corrigido rapidamente. Se seu sistema não tem qualidade -e testes fazem parte de qualidade- você não consegue isso. TI gasta fortuna das empresas reescrevendo sistemas simplesmente porque não foram feitos por profissionais, e profissionais se preocupam com a qualidade do que fazem. E isso inclui testes.


Não seja um amador.

39 Responses to “Programadores Profissionais Escrevem Testes, Ponto Final.”

  1. Eu também detesto quando dizem que testes desaceleram o desenvolvimento. Na verdade, a maior parte dos desenvolvedores que dizem isso não testaram TDD.

    valeuz…

  2. Ah, sobre o post no GUJ, a maior parte não discute testes em si, uma pena terem transformado a discussão em “meu time é melhor do que o seu”.

    valeuz…

  3. Alexandre Bairos says:

    “num mundo capitalizado não há tempo para testes”. Acho que nunca ouvi um argumento tão ruim. Não conheço o autor de tal pérola, mas é típico de retórica de péssima categoria. Uma boa sugestão de literatura a cerca de verificações de métodos é o artigo http://pt.wikipedia.org/wiki/Prova_dos_nove . É importante ressaltar que essa técnica não cobre 100% dos casos. :)))

  4. Alan Rubin says:

    Assino em baixo: 100% apoiado !

  5. Marcos Peron says:

    Bom, eu respeito quem faz sem teste, mas não gostaria de dar manutenção, nem continuar um projeto assim.

    Já peguei sistemas assim, e francamente, é triste.. quando é pequeninho, tranquilo, vc meche aqui e testa tudo.

    Agora quando o bicho cresce, sempre penso: ah se tivesse teste…

    Parabés pelo post!

    sds

  6. Danilo Sato says:

    Muito bom o post.
    Nessas horas que eu percebo como BDD é muito mais apropriado que TDD. O fato de tirar a palavra teste já elimina metade desses problemas. Duvido que alguém diga que programa sem pensar. Com BDD, você deixa isso explícito em código executável. Documentação/especificação/teste automatizado, chame do que você quiser, mas dizer que isso é desperdício de tempo é um absurdo.

  7. Existem n maneiras de se fazer um bom software, isso não quer dizer que se você deixar de usar uma ou outra o software seja ruim.
    Claro antes de me falarem mal, eu sou a favor de fazer testes unitários SIM, porem se o meu software não tiver testes não quer dizer que este seja ruim e que por isso eu sou um amador.
    Vale lembrar que apenas o software não foi testado, o que é péssimo, mas não por esse motivo isolado ele pode ser caracterizado com um software ruim, e se ele funciona como deveria eu então serei visto como um excelente profissional.

  8. Ronildo jr…
    100% o que você citou!!!

  9. pcalcado says:

    @ronildo

    Como você pode ter o mínimo de confiança de que um software funciona sem testes?

    E mais, um sistema orientado a objetos é composto por milhares de pequenos sisteminhas, são o que chamamos de objetos. Como você consegue ter um mínimo de garantia de que se alterar o sisteminha #2423 o #224 continua funcionando como antes?

    Desenvolvedores profissionais querem desenvolver com qualidade. Há mais de duas décadas que testes de software são aceitos como parte importante do controle de qualidade de software, é algo tão profundo e básico que mesmo correntes divergentes como agilidade e CMMi/MPS.br reconhecem seu valor.

    Se o software não tem qualidade você pode enganar como bom profissional mas não o seria. Se você quer abrir mão de testes como ferramenta para atingir um mínimo de qualidade necessária para algo ser profissional e não feito por um amador tudo bem.

    Só realmente espero que sugiro algo para colocar no lugar, e já sabemos que ‘boas práticas de oo’ e ‘programação defensiva’ são bravatas.

  10. pcalcado says:

    Aliás, esta parte do ’se funciona sou um bom profissional’ é exatamente o que eu falo no último parágrafo do texto.

  11. Bruno says:

    A maioria está preocupada em fazer os testes microsoft based, vai pro cliente e ele berra no teu ouvido. Brincadeiras a parte, excelente post, normalmente teste como já dito é associado a perda de tempo, mas vários títulos falam ao contrário.
    Resumindo, brow, you’re the guy!

  12. Perfeito, falou tudo que o pessoal deveria saber…
    Entregar sw sem testes é falta de vergonha na cara…

    Abraços Shoes =)

  13. Bruno Laturner says:

    “Vale lembrar que apenas o software não foi testado, o que é péssimo, mas não por esse motivo isolado ele pode ser caracterizado com um software ruim, e se ele funciona como deveria eu então serei visto como um excelente profissional.”

    Se o software não foi testado durante seu desenvolvimento, se ele _aparentar_ funcionar como deveria, você _poderá_ ser _visto_ como um excelente profissional.

    É muita incerteza, não acha? Que tal:

    O software foi testado(como em TDD e derivados) durante o seu desenvolvimento, ele funciona corretamente, e sou um excelente profissional por conta disso (não pelo mérito de ter um software funcionando, mas por como você o desenvolveu).

  14. [...] das frases que o Eric falou me lembrou a discussão que rolou na semana passada no GUJ sobre testes, TDD e etc: “Estamos no ano do Test-Driven Development e criar designs [...]

  15. @pcalcado
    Como você pode ter o mínimo de confiança de que um software funciona sem testes?

    Se após o término do sistema ele atender as necessidades programadas, eu então vou ter o mínimo de confiança !

    Lógico, eu espero que a força aérea brasileira nunca contrate um programador assim, mas um gerente de software house pode muito bem contratar.

    Portanto eu acho que as pessoas devem aplicar os testes conforme as suas necessidades, o TDD pode me ajudar bastante, porem não acho certo ver isso como regra, e quem não pratica é amador.

    Eu entendo a preocupação do Philip quando escreveu:
    “Poxa, se esses caras que fazem todos estes frameworks não usam testes por que eu vou usar?”

    Eu respondo:
    “Simples, porque as suas necessidades são diferentes”

    Portanto, se vc quer distribuir o seu software de uma forma mais prazerosa, siga o conselho Philip, porem não faça disso uma regra e muito menos menospreze os seus colegas de trabalho pelo fato de não testarem o sistema.

  16. pcalcado says:

    E como você sabe que ele atende às especificações se você não testou? E como sabe que ele continua atendendo após uma alteração? Deixa o usuário testar por algumas horas? Você pode dizer que a aplicação atende mas não consegue provar isso. Você pode estar certo ou errado mas não pode afirmar, você não oferece nenhuma alternativa aos testes.

    Há décadas que testes são parte integrante de engenharia de software (e das outras também). Um avião cair é muito ruim mas um cliente perder a chance de fechar o negócio mais importante da empresa dele porque digitou um caracter especial num formulário web também.

    Bugs acontecem com ou sem testes mas acho que é unanimidade que utilizar testes automatizados diminui a incidência de bugs. Além do mais uma vez que você prova a existência de um bug com um teste se protege contra o ressurgimento deste. Como ter algo parecido sem testes?

    Mas não ligue, ser amador não significa que você não faz coisas legais, que até eventualmente funcionam. Só significa que você não liga muito para o que faz, se ligasse teria se profissionalizado ;)

  17. “E como você sabe que ele atende…”
    Na minha humilde opinião eu acho que vc esta confundindo. Não é possivel provar que o sistema não possui bugs, mas vc pode afirmar que o sistema atende as necessidades, pois diante das necessidades existem os bugs, assim como o windows atende as minhas necessidades mesmo possuindo bugs.

    “um cliente perder a chance de fechar o negócio…”
    Nesse caso, ambos os software são criticos, portanto cabe ao programador verificar essas necessidades e implementar os devidos testes, seja eles qual for.
    Para que todos entendam melhor, imagine as metodologias de teste usada nos softwares da aviação civil. Ok? Agora vc acha certo eles chamarem a gente de amador porque a metodologia do TDD nao atende as necessidades ?

    “Bugs acontecem com ou sem testes…”
    Que bom que compartilhamos a mesma opinião, acho que vc pode perceber, porem cabe ao programador decidir qual a real necessidade dos testes dentro da sua empresa.

    “Mas não ligue, ser amador não significa que você…”

  18. pcalcado says:

    Como você acha que a Microsoft atende às suas expectativas? A Microsoft possui um tester por desenvolvedor, além de praticar metodologias ágeis (que incluem TDD) e ter seus próprios frameworks de teste. Só assim eles colocam um produto no mercado que, mesmo tendo bugs, atende minimamente aos seus usuários. Sem sequer testar o software você não tem nem a garantia mínima.

    (quase) Todo software é crítico, Ronildo. Pode não ser pra você mas pro seu cliente é. Software de missão crítica são mais testados que os sistemas que não possuem tantas exigências mas isso não é desculpa para não testar seu software. Sim, se não testa é amador.

    Ronildo, o ponto é: existe uma qualidade mínima para que você não seja um amador. Testes são uma ótima e comprovada maneira de se atingir isso, se você não quer testar é bom colocar outra verificação no lugar. Minha pergunta desde o primeiro comentário é: o que você sugere? Se compilar tá pronto? Isso é qualidade que se espera de um profissional?

    Se alguém faz um sisteminha em casa para provar um conceito e resolve não testar é uma coisa. Se ela presta serviços profissionais e não faz verificação é outra. É um amador no lugar de um profissional.

  19. “Como você acha que a Microsoft…”
    Eu so estava citando um exemplo, não quero dizer que a microsoft não testa o sistema, mas quero dizer que eles testam conforme a necessidade, e essa necessidade esta relacionado ao atendimento dos clientes.

    Eu diria que todo software tem um nivel crítico, e cabe ao programador decidir esse nivel e fazer os testes necessário para atende-lo.

    “Ronildo, o ponto é: existe uma qualidade mínima…”
    Digo novamente… não cabe a nós definir esse limite.

  20. pcalcado says:

    Novamente: como você sugere que alguém verifique se uma coisa (um SO, um controlador de turbina, um gerenciador de RH) segue sua especificação? Se você não verifica você não pode afirmar que segue a especificação, que vai atender ao seu cliente como ele espera. Se não verifica é amador.

    O mínimo que se espera de um profissional é que ele cumpra aquilo para o qual é pago para fazer. Se você nem sequer possui uma forma de fazer esta verificação não pode se enquadrar como profissional.

  21. Eu sugiro que o programador use o TDD, mas existem n maneiras de verificar se o sistema funciona. Eu diria que hoje usando TDD eu sou um profissionar mais qualificado, mas não vejo os meus projetos de 3 meses atrás como amador, pois so conheci o TDD nos ultimos meses.

    Mas enfim, parabens pelo artigo e amanhã boa palestra no Conexão Java 2007. Eu vou estar lá é claro.

  22. [...] vantajoso é o uso de testes no desenvolvimento de software. Infelizmente nosso mercado local é amador quando se fala em testes, a maioria dos nossos desenvolvedores, arquitetos, analistas, empresários e empresas não tem esta [...]

  23. [...] desenvolvedores profissionais escrevem testes (e gerar você deve começar por aí. Você sabe muito pouco sobre este sistema e o teste vai te [...]

  24. djael santos says:

    gostaria de saber o curso ideal para me formar e graduar na qual nao sei

  25. [...] A pré-condição essencial parar refatorar é a existência de testes sólidos!!! E, programadores profissionais escrevem testes! [...]

  26. [...] em tdd, testes Muito tem se falado e se escrito sobre a realização de testes no processo de desenvolvimento de software. Bastante [...]

  27. [...] tem se falado e se escrito sobre a realização de testes no processo de desenvolvimento de software. Bastante [...]

  28. [...] Convenhamos, o caso do Knuth é um caso a parte. Ele está na ativa desde os anos 60 quando nossos pais ainda eram adolescentes, e possivelmente por isso tem práticas e opiniões que não necessariamente se aplicam às situações de hoje. É claro que ele merece todo o respeito por tudo que ele fez e faz pela computação, mas não acho que a opinião dele sobre práticas ágeis em especial possa ser levada em consideração ao pé da letra. E o que mais me preocupa nisso tudo é que, por ele ser um ícone da computação, as pessoas tomem tudo que ele falou como verdade absoluta e comecem a achar que testes unitários não servem para nada, quando na verdade eles são essenciais para qualquer programador profissional! [...]

  29. Amanda says:

    A maioria dos projetos em que participei recriminava a prática de testes devido ao tempo “gasto” (não seria investido?).
    Na última empresa em que fui colaboradora chegaram ao ponto de me dizerem que sou “perfeccionista” e, por isso, não tenho perfil de consultora.
    Simplesmente por corrigir código legado, testar métodos, limpar código e questionar a arquitetura do sistema. Se há um defeito é preciso corrigí-lo, não? Independente de quem fez e quando.
    Quando questionaram meu desempenho como consultora procurei meus antigos colegas de trabalho e procurei um feedback. É muito desestimulante empregar valores de desenvolvimento que não se adequam aos valores da empresa.
    Felizmente, o feedback recebido foi excelente e, apesar de admitir que muito preciso aprender - inclusive a melhor selecionar oportunidades de emprego, fiquei confiante. Não sou perfeccionista, apenas não me engano.
    Muito bom saber que existem pessoas - organizações? - que compartilham dos mesmos valores.
    Se é para fazer, que seja bem feito.

  30. [...] A pré-condição essencial parar refatorar é a existência de testes sólidos!!! E, programadores profissionais escrevem testes! [...]

  31. [...] do software. Um programador profissional deve escrever testes, como já disse Phillip Calçado aqui! Como não há testes, a refatoração foi dividida em sprints bem curtos de no máximo uma semana. [...]

  32. [...] tem se falado e se escrito sobre a realização de testes no processo de desenvolvimento de software. Bastante [...]

  33. [...] TDD. Não foi maldade, nem desejo de menosprezar alguém. Há pouco reli um artigo do Shoes chamado Programadores Profissionais Escrevem Testes, Ponto Final. Leiam, pensem, tentem aplicar alguma coisa. Sobre o estômago, gostaria de pedir a ajuda de algum [...]

  34. Bingo ! Concordo plenamente.

  35. [...] Programadores Profissionais Escrevem Testes, Ponto Final. [...]

  36. [...] Programadores profissionais escrevem testes. Ponto final [...]

  37. Eduardo says:

    Bom, sou totalmente a favor e inclusive na empresa que trabalho já estamos utilizando código de teste, mas não concordo no radicalismo de falar que se o programador não usa teste ele é amador… Isso é uma mentira, pois para programar, existem várias técnicas que podem ser usadas, o que irá definir se é bom ou não, não é apenas se faz testes ou não. Um programa feito totalmente em teste pode ter vários problemas caso os testes forem criados de forma amadora…

  38. @romildo

    Uma pessoa, que eu não lembro quem foi disse: O bom programador nunca confia no que ele fez, e muito menos confia na sua própria memória. Pra isso existem os testes. Mesmo que você seja um programador excelente, uma hora o sono, o cansaço, o stress, enfim, fatores externos vão fazer o seu código sólido virar uma casquinha de gelo.