Como introduzir TDD à minha vida?

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

dreamspeaker wrote:

sergiotaborda wrote:... É por isso que se chama Desenvolvimento guiado por teste (TDD). Em TDD raramente ha a necessidade de mocks porque vc não está simulando o funcionamento do sistema, vc está escrevendo como ele vai se comportar. Claro que mocks são uteis em situações complexas que acabarão aparecendo, mas não são o foco nem a ferramenta principal...

Ando estudando TDD esses ultimos dias, muito bom seu post. Mas fiquei meio confuso no "raramente". Escrever como o sistema vai se comportar não indica o uso de recursos externos? Claro que a super utilização de mocks mostra que o que você esta escrevendo provavelmente está com um acoplamento muito alto, mas via de regra sempre há algum acoplamento. Esse "raramente" é tão "raramente" assim?

Quando vc usa TDD vc não tem as classes ainda. Vc está criando-as e sendo guiado pelos testes para as criar.
É um processo de desenvolvimento de "dentro-para-fora" no sentido que coisas como banco e jms só vão chegar no fim.
Então, vc passa quase todo o desenvolvimento sem estar simulando nada. Vc está correndo o sistema como ele tem que ser.
No fim do desenvolvimento vc aplica a tecnica normal de testes e ai tudo tem que ser testado. É ai que entram os mocks. Mas isso acontece quer vc use TDD ou não.

O raramente vem de que, às vezes, em certas circunstancias, vc precisa de um mock durante o desenvolvimento. Sobretudo quando vc tem alguma comunicação com outro sistema ou mecanismo que vc ainda não conhece, etc.. Por exemplo, vc invocar um webservice que não é seu. Ai vc é "forçado" a usar o mock durante o TDD.

E não, o como o sistema vai se comportar não indica uso de sistema externos. É relativamente simples abstrair esses sistemas utilizando classes especializadas e implementações delas que simplesmente simulam o real. Isso é naturalmente util ao mexer com banco de dados, por exemplo, em nunca durante o desenvolvimento vc usa um banco realmente. Vc usa uma classe(biblioteca) que simula o banco. Repare que o foco do TDD é desenvolver a aplicação (tal como outras DD por ai como MDD, DDD , etc...) e não desenvolver os testes em si mesmos. Eles são um sobre-produto que resulta naturalmente da metodologia.

Detalhe, desenvolvendo com TDD vc obtem testes. Não necessariamente vc obtém bons testes ( com a mesma qualidade e profundidade necessária aum teste que visa ter cobertura máxima, por exemplo)

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

Bruno Laturner wrote:Ótima resposta Sérgio!

Eu já faço a distinção entre fazer testes e fazer TDD, meio que coloquei isso na frases grifadas. "Como começo a fazer testes" é o meu objetivo inicial, o começo de tudo, "Como tornar isso um hábito, um TDD de fato" é o meu objetivo final.

Concordo demais com que fala de exemplos de revistas, elas se focam demais em "testar que instrumentos musicais estão afiados", pouco falam de testar se os músicos sabem tocá-los e ler as partituras, e nunca falam sobre como garantir que a orquestra ser um sucesso.

Outra, por acaso testar as partes garante que o todo funcione?

Não. Não garante. Porque aquele pedacinho de codigo que cola as partes tb pode ter erro. É por isso que existem testes de integração. Mais, as peças por si só funcionam, mas cada uma com logica diferente. Quando se unem elas não são compativeis conceptualmente (embora as suas interfaces de codigo sejam)

No caso que descreveste, não é demais ter ver se o email foi enviado certo, se a mensagem Jms chegou, verificar o que no banco mudou, de o resultado do processamento do arquivo está certo? Testar cada um em separado já não garantiria tudo?

não, não é demais. Testar nunca é demais. Esse é um fator bom e ruim, já que é facil se desmoralizar por não ter testado tudo o que podia ( já que o que podia ser testado é muito vasto)
No caso do email, por exemplo, ele pertence a um processo. E é o processo que vc está testando, não o envio fisico do email ( isso o pessoal da API de JavaMail já fez) . Por exemplo, o usuario é cadastrado e a senha enviada por email. Se o email não é enviado corretamente o usuário não pode ser salvo (não pode dar o commit) porque assim teriamos um usuário sem acesso ao sistema. O mesmo ao contrario se o banco dá pau não ha pq enviar o email.
Mas quando vc testa isto vc não envia email para ninguem com JavaMail. Vc simula. E simula que o envio deu problema (lançando um exception).
Testes de integração ou de processo são tão ou mais importantes que os de unidade. são eles que realmente garantem o sistema.

Um programador mentecapto nunca irá colocar o programa a funcionar por muitos testes que existam.

Conseguirá se o que ele fizer passar em todos os testes; All green. Como você disse "A preocupação é como o que a classe deve fazer e não como ela deve fazê-lo."

Se bem que se ele consegui essa "façanha", ele não será mentecapto.

O ponto é que se o teste dá vermelho e o programador é incompetente ele nunca o fará ficar verde. Não é adicionando mais testes que vai ficar verde, é treinando o cara. Enfim, o conhecimento do programador ainda é mais importante que os testes. Se o cara faz testes mas apenas porque é mau programador, isso não é uma boa utilização dos testes ( é como ficar fazendo debug de tudo o que vc escreve a cada linha que vc escreve pq vc não tem a certeza de que fez certo. )

sergiotaborda wrote:...E não, o como o sistema vai se comportar não indica uso de sistema externos. É relativamente simples abstrair esses sistemas utilizando classes especializadas e implementações delas que simplesmente simulam o real. Isso é naturalmente util ao mexer com banco de dados, por exemplo, em nunca durante o desenvolvimento vc usa um banco realmente. Vc usa uma classe(biblioteca) que simula o banco....

Aí que eu queria chegar. Eu posso não usar mocks o tempo todo como eles são do lado do teste (mocks de biblioteca, como jMock), mas de alguma forma e em algum momento eu preciso simular meus recursos externos (como BD), e isso não é raro.

E uma classe que simula o real, no meu entendimento, não deixa de ser um mock também!

Obrigado!

GUJ Expert Membro desde: 18/02/2008 16:17:53 Mensagens: 3002 Offline

Então Sérgio, por onde você começa um teste, como o faz no dia a dia? Como o caso de uso se transforma em testes?

Pergunto por que os casos podem ser muito gerais ou num nível muito alto, sendo que os testes mais unitários são aqueles que estão lá em baixo na cadeia, testando a base do sistema. Como você identifica as tuas unidades?

Disse que o desenvolvimento é de "dentro para fora", mas é necessário ter uma boa visão de tudo antes de escrever teu primeiro teste.

Tem alguma macete/dica para começar com os testes ou é só com a experiência?

Olá

Este tópico está muito bom. Gostei muito dos links que passaram.

Antigamante, no tempo em que ninguém falava de testes, que os programas eram lotados de System.out.println, passei por aqui e quando o chique era o chamado desenvolvimento top down, eu muitas vezes discutia com os top downzistas argumentando que sentia necessidade de fazer coisas bottom up.

É claro que levava pedrada de todo jeito porque estava violando um princípio básico da época que era primeiro pensar, pensar, pensar e pensar mais um pouquinho e só depois começar a fazer. Mas o que sentia era necessidade de ver funcionando algoritmos que seriam posteriormente incorporados na solução. Era como testar as ideías. Ainda bem que hoje ninguém mais pensa em top down e outras cascatas.

Encaro o TDD mais ou menos do mesmo jeito. É poder partir sabendo que o principal vai dar certo.

Vantagens? A principal, como o Paulo salientou, é que o sistema redundante fica naturalmente mais desacopladinho e para mim mais fácil de entender.

E devemos testar tudo para obter 100% de cobertura? Isto já acho exagêro em muitos casos mas chegar perto é muito tranquilizador.

[]s
Luca

GUJ Expert Membro desde: 18/02/2008 16:17:53 Mensagens: 3002 Offline

Gostei bastante deste screencast.

Me fez pensar numa coisa: quando a classe tem responsabilidades demais você faz tantos testes que acaba ficando cansado, e assim segue refatorando a classe em duas ou mais delas, refatora também os testes em mais classes e só para não ter que testar as mesmas coisas sempre.

Acho que o relato de uma pessoa de umas das equipes que estou colocando o conceito de qualidade/agilidade resume muito bem o que acontece com o desenvolvimendo com TDD, "se tem uma segurança muito grande de poder alterar qualquer coisa e saber exatamente onde os problemas vão refletir!".

Quando se falam por exemplo em análise de riscos, nada mais prático de alterar o teste, executar e ver quais pontos podem ser atingidos por aquela alteração, isso realmente da uma segurança na hora de se fazer alterações, óbvio que um bom nível de cobertura é essencial para isso.

Luca wrote:Olá

Este tópico está muito bom. Gostei muito dos links que passaram.

Concordo. IMHO, tópicos desse tipo é que fazem com que bons desenvolvedores ainda estejam aqui no GUJ.

Luca wrote:Antigamante, no tempo em que ninguém falava de testes, que os programas eram lotados de System.out.println

Os meus ainda tem bastante disso. Sem contar a quantidade de comentários existentes... é um terror.
O debugger entra nessa parte de testes? Porque vejo muitas pessoas falando (tá certo que é em RoR) que não usam mais o debugger. Provavelmente me enganei em alguma coisa.

Luca wrote:
Encaro o TDD mais ou menos do mesmo jeito. É poder partir sabendo que o principal vai dar certo.

Vantagens? A principal, como o Paulo salientou, é que o sistema redundante fica naturalmente mais desacopladinho e para mim mais fácil de entender.

Nessa parte eu já pude vivenciar algumas coisas. Nas férias passadas, quando estudava Java, eu notava que o desenvolvimento em geral era muito bem feito (mesmo eu não sabendo o que fazia direito). Eu sempre escrevia as classes de teste antes de terminar a classe "real" (dica do livro Head First).
O problema foi que, com as aulas da faculdade, 200 trabalhos pra implementar e escrever, é complicado. Como vocês lidam com o tempo, se ele for curto, de fazer os testes dessa forma? Eu concordo que é mais rápido do que testar depois da classe pronta (a isso sem dúvida alguma). Mas leva muito tempo?

Abraço.

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

Esse link discute estilos de TDD:

http://martinfowler.com/articles/mocksArentStubs.html

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

Bruno Laturner wrote:Então Sérgio, por onde você começa um teste, como o faz no dia a dia? Como o caso de uso se transforma em testes?

Pergunto por que os casos podem ser muito gerais ou num nível muito alto, sendo que os testes mais unitários são aqueles que estão lá em baixo na cadeia, testando a base do sistema. Como você identifica as tuas unidades?

Disse que o desenvolvimento é de "dentro para fora", mas é necessário ter uma boa visão de tudo antes de escrever teu primeiro teste.

Tem alguma macete/dica para começar com os testes ou é só com a experiência?

Na realidade eu também ando à procura do mesmo que vc. Me custou muito tempo diferenciar entre TDD e Programação Orientada a Teste ( que nada mais é que boa OO + JUnit da vida) por isso fiz questão de explicar a diferença.

No projeto MiddleHeaven que tou conduzindo no tempo livre uso o TDD para implementar as features. Na realidade uso uma mistura. Eu tenho o modelo +- na cabeça e uso os testes para experimentar na prática. Não são testes exaustivos. (como falei, esse não é o objetivo do TDD). Eu acho bastante util porque força o desacoplamento quer vc queira ou não

As minhas unidades são normalmente conjuntos de classes (mini API) ligadas por herança ou delegação. (de novo, aqui eu estou preocupado com o desenvolvimento, não com cobertura) e esta "inspeção" de desacoplamento é muito importante quando se constrói um framework.

Cobertura tb acho um porre. Como o Luca tb irrealista na prática, embora na teoria seja excelente se for alcançado. É um excelente trabalho de voluntariado

(ou para um equipa de testers. Se vc tiver uma)

No trabalho a política não é muito orientanda a TDD ou qq DD na realidade, então eu somo esses conceitos sempre que posso. É um work in progress na realidade. ja que como são filosofias, ha um trabalho de convencimento. Normalmente testamos as classes mais criticas ou as que são mais complexas ou mais centrais ( normalmente classes do tipo Services do DDD). Mas não todas e não ha uma procura real de cobertura 100%.

Eu acho POT e TDD muito util, mas dificil , custosa e demorada. Os resultados são otimos, mas ha muito tempo sendo investido. Não sei se, na balança, realmente compensa...

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

dreamspeaker wrote:

sergiotaborda wrote:...E não, o como o sistema vai se comportar não indica uso de sistema externos. É relativamente simples abstrair esses sistemas utilizando classes especializadas e implementações delas que simplesmente simulam o real. Isso é naturalmente util ao mexer com banco de dados, por exemplo, em nunca durante o desenvolvimento vc usa um banco realmente. Vc usa uma classe(biblioteca) que simula o banco....

Aí que eu queria chegar. Eu posso não usar mocks o tempo todo como eles são do lado do teste (mocks de biblioteca, como jMock), mas de alguma forma e em algum momento eu preciso simular meus recursos externos (como BD), e isso não é raro.

E uma classe que simula o real, no meu entendimento, não deixa de ser um mock também!

Ai é que está. Eu acho que deixa. O objeto mock é especificamente artilhado para o teste. Quando vc usa uma implementação diferente isso não é um mock. Por exemplo, usar um repositorio que guarda em memoria em vez de um que grava no banco não é usar um mock.
Vc usa o mock quando ele está vinculado ao teste. Por exemplo, ele contem atributos, que será alterado espeficicamente pelo/para o teste e depois vc vai lá , ler esse campo e ver se tem o valor certo.

então, enquanto o uso de implementações diferentes dos mesmos serviços é comum, o uso de mocks (objetos especiais destinados explicitamente ao ambiente de teste e nunca ao de produção) são raros.

Andre Brito
Concordo. IMHO, tópicos desse tipo é que fazem com que bons desenvolvedores ainda estejam aqui no GUJ. ++

Concordo plenamente estou acompanhando e colocando os blogs indicados no meu favoritos.

GUJ Expert Membro desde: 18/02/2008 16:17:53 Mensagens: 3002 Offline

Paulo, vi que a última postagem no blog da Caelum foi sobre Integração Contínua, que cai bem no tema que temos aqui.

Como vocês fazem aí na Caelum para transformar idéias ou casos de uso em testes? Qual o pontapé inicial? Fazem uso de BDD?

GUJ Master Membro desde: 16/12/2004 17:09:19 Mensagens: 1787 Offline

Sobre a entrevista do Knuth, acho que às vezes os testes podem mascarar maus programadores...tipo, o cara programa se preocupando apenas em fazer o código passar no teste, e acha que a barra verde do JUnit é por si só sinônimo de código de qualidade...

Acho que existe um certo exagero de pessoas que vendem o uso de testes como algo incrível, como se isso fosse redimir os maus programares, e a questão da qualidade do código fica meio de lado...

GUJ Expert Membro desde: 18/02/2008 16:17:53 Mensagens: 3002 Offline

renato3110 wrote:Sobre a entrevista do Knuth, acho que às vezes os testes podem mascarar maus programadores...tipo, o cara programa se preocupando apenas em fazer o código passar no teste, e acha que a barra verde do JUnit é por si só sinônimo de código de qualidade...

Acho que existe um certo exagero de pessoas que vendem o uso de testes como algo incrível, como se isso fosse redimir os maus programares, e a questão da qualidade do código fica meio de lado...

Ao meu ver a qualidade do código melhora por que melhorar é a maneira que dá menos trabalho. Testes forçam a melhora.

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