O programador profissional precisa de testes unitários?

This message was edited 1 time. Last update was at 01/03/2008 18:24:52

O InfoQ está agitado em relação a testes unitários e a TDD. Primeiramente Cedric Beust, PhD e engenheiro senior do Google, fala sobre desenhar classes para testes, eliminar static, grande uso de encapsulamento, etc:

http://www.infoq.com/presentations/beust-popescu-designing-for-testability

Quem programa com testes unitários sabe o quão viciante essa prática pode ser: queremos sempre aumentar a cobertura dos nossos testes, o número de testes e o quão desacopladas nossas classes estão.

Uma outra discussão também é apresentada no InfoQ, falando sobre o "programador profissional" de hoje em dia:

http://www.infoq.com/news/2008/03/cockburn-testing-guts

Bob Martin chega a dizer que "hoje em dia é irresponsabilidade do desenvolvedor entregar uma linha que não tenha sido executada em um teste unitário".

A pratica de testes unitários, como fazer, vantagens e desvantages são tópicos amplamente discutidos no GUJ, causando muita polêmica.

O que você acha dos testes unitários? Esta prática é adotada na sua empresa? Quais os resultados que você obteve?

Paulo Silveira wrote:Bob Martin chega a dizer que "hoje em dia é irresponsabilidade do desenvolvedor entregar uma linha que não tenha sido executada em um teste unitário".

Concordo com o Bob na teoria, e acho que esforcos nao devem ser poupados na medida do que eh pratico pra se automatizar todos os testes possiveis. O problema eh quando nao eh pratico automatizar alguns deles, ou quando rodar todos os testes torna sua integracao continua nao tao continua assim. Fora isso, 100% de acordo.

Paulo Silveira wrote:Esta prática é adotada na sua empresa?

Impreterivelmente, sim. ThoghtWorks rula

Paulo Silveira wrote:Quais os resultados que você obteve?

Otimos. O design das aplicacoes eh assustadoramente melhor, e todo tipo de metrica que a gente ja passou nos projetos eh melhor de maneiras significativas (e a TW lancou um whitepaper sobre essas metricas que eu nao estou conseguindo achar agora por estar razoavelmente bebado/cansado/sem saco).

This message was edited 10 times. Last update was at 01/03/2008 23:11:23

Estou brincando com Ruby e não sei se é falta de experiência minha com a linguagem ou realmente Ruby e Testes Unitários nasceram um para o outro. Minha impressão é que em Ruby vc realmente pode quebrar tudo mudando uma linha, mesmo que vc saiba exatamente o que está fazendo, pois sua característica dinâmica vai de encontro a maior robustês de uma linguagem estática (compile-typed) como Java.

Some-se a isso também a robustês das IDE Java, que te permite um excelente controle do big picture, call hierarchy, etc.

Em todas as empresas que trabalhei, testes unitários eram encorajados mas não exigidos. Vc acaba tendo que escolher entre um controle maior sobre o que vai para producão ou um ambiente mais dinâmico onde as pessoas devem se responsabilizar pelo seu código (tendo ou não testes unitários). Um controle de releases é fundamental, já que na descoberta de um eventual bug o código deve ser rollbackeado imediatamente para a última versão que funcionava.

Achar que um sistema *com* testes não terá bugs é tão errado quanto achar que um sistema *sem* testes não terá bugs. As chances de um programa com testes ter menos bugs do que um programa sem testes é obivamente MAIOR. Mas o quanto MAIOR vai depender de um monte de coisas.

Isso depende da característica da empresa. Do mesmo jeito que existe esquerda e direita, RUP e XP, Java e Ruby, etc. existem empresas e projetos que um controle total e testes totais serão exigidos e outras onde outras coisas serão mais valorizadas. Depende do seu time, do tamanho da sua equipe, do estágio do seu sistema, qualidade do código e por aí vai...

Numa empresa onde o sistema não possui testes *unitários*, vc precisa saber exatamente o que está fazendo, se possível executar outros tipos de testes antes de colocar o sistema em produção. Se esse esquema não está dando certo, então há duas opções: contrata-se outro profissional ou se a primeira opção já foi tentada muitas vezes sem resultado deve-se parar tudo para refazer o sistema ou adicionar testes unitários em tudo. Código spagetti sem testes modificado pelo o autor ou pior ainda por outra pessoa é realmente receita para sérios problemas (bugs).

Uma consultoria desenvolvendo um sistema para uma empresa cliente, só tem a ganhar com testes unitários. Primeiro gastará mais horas, segundo entregará um produto com seguro. Qualquer cliente sensato não vai se incomodar de pagar um pouco mais para ter testes unitários, e todos ficarão felizes.

Como vemos, cada caso um caso. Cada situação uma situação. Isso vale pra ambas as partes da discussão sobre testes: "Quem trabalha muito com um martelo terá a tendênca de achar que todo problema é prego." Isso é fato. O que não se deve é sair martelando a cabeça de todo mundo.

Apenas minha opinião pessoal...

This message was edited 1 time. Last update was at 01/03/2008 21:43:26

hoje em dia é irresponsabilidade do desenvolvedor entregar uma linha que não tenha sido executada em um teste unitário".

com certeza isso é fato, o problema é aqui existe empresas que infelizmente não fazem uma gerência correta do projeto(se é que podemos denominar isso de Empresa, ou aquilo de gerentes de projeto) e precisa de 1000 linhas pra antes de ontem, ai não tem jeito vai umas linhas sem teste

e depois vai na correção

O que você acha dos testes unitários? Esta prática é adotada na sua empresa? Quais os resultados que você obteve?

hoje sim, estou realizando constantemente testes unitários e o resultado é incrível, projeto fluindo e cliente satisfeito

Onde eu trabalho, existem certos trechos que fazem interface com um hardware em que os custos para se produzir um mock foram realmente impeditivos.

Especialmente pq um bom mock teria que simular várias das situações de concorrência, parse de diversos tipos de mensagem, etc.

Em todos os outros trechos, há testes unitários.

Onde eu trabalho há uma série de coisas que precisamos mudar, dentre elas, a falta de testes unitários.

Mas estamos prestes a marcar reuniões para analisar a qualidade dos softwares produzidos por nós, e eu pretendo enfatizar, dentre outras coisas, a importância dos testes unitários pra nós

saoj wrote:Uma consultoria desenvolvendo um sistema para uma empresa cliente, só tem a ganhar com testes unitários. Primeiro gastará mais horas, segundo entregará um produto com seguro. Qualquer cliente sensato não vai se incomodar de pagar um pouco mais para ter testes unitários, e todos ficarão felizes.

Eu nao sei se eu consigo descrever exatamente o quanto este argumento esta errado, saoj. Mas eu quero ver (e pago bem!) voce provar pra mim que um time de desenvolvedores com boa experiencia e um ambiente sem nenhum fator a se considerar um risco ao projeto demora mais pra entregar com o uso de testes automatizados.

E, pelo amor de zahl, robustez eh com 'z' e nao tem acento.

cv wrote:
Eu nao sei se eu consigo descrever exatamente o quanto este argumento esta errado, saoj. Mas eu quero ver (e pago bem!) voce provar pra mim que um time de desenvolvedores com boa experiencia e um ambiente sem nenhum fator a se considerar um risco ao projeto demora mais pra entregar com o uso de testes automatizados.

Apenas achei que para escrever e manter os testes gasta-se homem-hora e brain power. Acho que vc quer dizer que o processo como um todo é agilizado com a introdução de testes unitários. Devido a sua maior experiência no assunto aceito que vc muito provavelmente está certo. Ainda mais se a linguagem em questão for Ruby.

saoj wrote:Apenas achei que para escrever e manter os testes gasta-se homem-hora e brain power.

E debugar e integrar codigo que nao funciona sempre que alguem muda alguma coisa eh "gratis"? Nao entendi a sua logica, aqui.

saoj wrote:Ainda mais se a linguagem em questão for Ruby.

E pq seria diferente com Java? Voce tem alguma metrica que eu nao conheco?

Virtual Machine Man Membro desde: 23/10/2007 10:08:29 Mensagens: 684 Offline

E como voces preferem implementar testes unitarios, primeiro ou depois do codigo?

cmoscoso wrote:E como voces preferem implementar testes unitarios, primeiro ou depois do codigo?

Um ou mais testes de aceitacao, preferencialmente em algo executavel/automatizado por user story antes de comecar o desenvolvimento, e depois um teste unitario por...er, unidade.

De preferencia, usando Behaviour Driven Development; senao, vai com TDD mesmo.

Pessoal,

Na empresa onde trabalho, até hoje nao realizamos testes unitários.

E quando já se tem grande quantidade de códigos? Como fazer para adicionar testes?

Deixa o que já tem sem teste e faz apenas para os novos ou faz tudo?

This message was edited 4 times. Last update was at 02/03/2008 10:30:12

Senhores,

primeiramente eu acredito e utilizo testes unitários, porém, lendo estes artigos, acho que os iniciantes em java poderão cair no erro de programação por testes unitários ou programação para testes unitários.

Essa lógica, me faz lembrar dos irmãos Wright, em que desenvolviam os protótipos e depois, no jargão aqui do sul, soltavam penhasco abaixo e eperavam para ver se voava...

No fundo, essa prática, induz que ao se desenvolver códigos não se precisa de planejamento, de lógica e muito mesnos de experiência. Afinal simplesmentes, se o que você escrever passar nos testes, então seu código será bom...

Eu tive que fazer uma auditoria em um sistema recentemente, em que existia testes unitários para todos os POJOS da aplicação e para uma boa parte das classes de negócio... resumindo: testes mecanicos, sem valor algum, a ponto de encontrar em pojos, coisas do gênero:

Enquanto que nas classes que deveriam representar estados e implementar uma máquina de estado, sequer validava a transição de um estado para outro...

Outra prática que tenho visto em Curitiba, e a delegação da escrita dos testes para estagiários... com um detalhe importante, os mesmos estão construindo estes testes sem conhecimento das regras de negócios, sem o apoio mínimo de uma documentação... estão apenas escrevendo testes para apresentar ao contratante.

Logo, senhores, testes unitários não deveriam ter o valor que estão querendo dar, fazem parte do ciclo de vida de desenvolvimento de software, especificamente para a fase de testes e deveriam estar sendo menos cobrados na fase de desenvolvimento, ou sequer ser confundidade como parte do desenvolvimento.

A relevância dos testes unitários são proporcionais aos conhecimentos e experiência da equipe de desenvolvimento com relação ao ambiente, aos recursos disponíveis e do grau de definição das regras de negócios.

Em uma equipe experiente, com um escopo bem definido e uma boa documentação, eu rediziria a necessidade dos testes para faixas entre 3 e 5% do projeto, enquanto que no inverso, ou seja, em equipe pouco experiente e com regras de negócios pouco claras, eu recomendaria de 75 a 90% dos artefatos produzidos. (Os % são em relação a cobertura das unidades desenvolvidas)

fw

This message was edited 1 time. Last update was at 02/03/2008 12:17:57

Eu realmente acho viciante como o Paulo falou ao abrir o tópico. E é aí que mora o perigo, pois testes se tornam validadores de código de alto acoplamento. O pensamento voltado para classes e métodos ao invés aquiescer story cases e cenários específicos, que é o que o cliente (e até mesmo o sistema) espera no fim das contas, vide BDD.

Dieval Guizelini wrote:Logo, senhores, testes unitários não deveriam ter o valor que estão querendo dar, fazem parte do ciclo de vida de desenvolvimento de software, especificamente para a fase de testes e deveriam estar sendo menos cobrados na fase de desenvolvimento, ou sequer ser confundidade como parte do desenvolvimento.

Discordo completamente; testes unitarios sao parte do ciclo de desenvolvimento sim, e ate agora nao me mostraram um ciclo mais produtivo de desenvolvimento do que o red-green-refactor.

Notícias, artigos e o maior fórum brasileiro sobre Java