Estou começando a praticar TDD, e as vezes acontece de eu escrever um teste e ele já estar passando, devido ao código que eu escrevi para passar algum teste anterior se aplicar tambem a este. Assim as vezes eu não consigo seguir o ciclo Red->Green->Refactor, acaba ficando Green->Refactor
Isso pode indicar que estou fazendo algo errado?
Só vendo o código para poder opinar.
O ideal é você manter as classes e métodos o mais coeso possível, assim facilita tanto o entendimento do código como a escrita dos testes.
Esse teste especifico não vai atender ao conceito de TDD, mas agora vc precisa pesar na balança. Se este teste executa um fluxo diferente daquele que já esta escrito, mantenha-no. Se você realmente quer usar a metoldologia “à risca” pq é um kamikase maluco, aumente o escopo do teste até ele dar erro.
Minha opnião…mantenha o teste e continue com o próximo.
Minha opnião…mantenha o teste e continue com o próximo.
Sim, é o que estou fazendo
A minha pergunta foi por que talvez isso indique que eu estou fazendo algo errado, e portanto não estou aproveitando tudo que poderia com TDD…
[quote=magnomp]Minha opnião…mantenha o teste e continue com o próximo.
Sim, é o que estou fazendo
A minha pergunta foi por que talvez isso indique que eu estou fazendo algo errado, e portanto não estou aproveitando tudo que poderia com TDD…[/quote]
Entendi…e quais ferramentas vc utiliza para desenvolver esta técnica ? Você chega a testes funcionais ou apenas realiza testes de unidade ?
Até o momento realizo apenas testes de unidade, com JUnit e Mockito.
Para persistência uso o Hibernate, e quando os testes envolvem a camada de persistência eu configuro o Hibernate para utilizar um banco HSQL em memória
Então, você está escrevendo os testes primeiro? Ou você está alterando o teste já escrito?
Se você sempre cria o teste primeiro ele sempre vai falhar por que não existe implementação certo?
Agora se você faz a implementação e o teste passa de primeira, minha dica é: procure outras possibilidades de possíveis falhas na sua implementação.
Não falhou? Então Refatore e prossiga.
Se você alterou um código e o teste não mudou em nada, de duas uma, ou a lógica não mudou ou o teste está falho.
Eu acredito que seguindo dessa forma não fere o TDD.
Se você está criando testes para implementações já feitas você está invertendo a ordem das coisas e isso sim fere o TDD.
[quote=magnomp]Até o momento realizo apenas testes de unidade, com JUnit e Mockito.
Para persistência uso o Hibernate, e quando os testes envolvem a camada de persistência eu configuro o Hibernate para utilizar um banco HSQL em memória[/quote]
Se estiver escrevendo uma aplicação web, procure meios de utilizar o “Selenium + Maven + Java”
Para que isso funcione é preciso antes de mais nada possuir um protótipo fiel das telas que serão desenvolvidas, então vc atráves dos ids definidos no protótipo começa a escrever código que acesse a página e, por exemplo dê um submit sem definir os valores obrigatórios aí vc valida se foi apresentado uma mensagem de erro na tela.
Todo esse teste é escrito sem ter qualquer coisa a não ser um protótipo. Então quando vc rodar o teste ele vai falhar, pq a página não existe, aí vc define a página mas o teste falha pq ele não encontrou os inputs que deveriam estar lá…e por aí via…ao término vc consegue um teste mais próximo do funcional.
[]'s
O problema que voce esta descrevendo deve estar sendo causado por uma dessas situacoes:
Voce esta escrevendo testes redundantes, testando a mesma coisa num codigo ja implementado.
Voce esta com problema de coesao e acomplamento nas suas classes, um mesmo metodo/classe esta fazendo muita coisa e voce esta testando o resultado de um processo longo sem testar as partes desse processo.
Se for o primeiro caso, nao vejo problemas graves, exceto o fato do codigo ter sido implementado antes, mas tanto faz remover ou manter seu teste.
Se for o segundo caso, o ideal seria separar cada passo deste processo e testa-los separadamente, para depois testar todos integrados.
[quote=YvGa]O problema que voce esta descrevendo deve estar sendo causado por uma dessas situacoes:
Voce esta escrevendo testes redundantes, testando a mesma coisa num codigo ja implementado.
Voce esta com problema de coesao e acomplamento nas suas classes, um mesmo metodo/classe esta fazendo muita coisa e voce esta testando o resultado de um processo longo sem testar as partes desse processo.
Se for o primeiro caso, nao vejo problemas graves, exceto o fato do codigo ter sido implementado antes, mas tanto faz remover ou manter seu teste.
Se for o segundo caso, o ideal seria separar cada passo deste processo e testa-los separadamente, para depois testar todos integrados.[/quote]
Só acho que no 1º caso também está errado, já que o refactor não se aplica apenas a classe que você está testando, mas sim para os testes também!!