TDD, teste que não falha

JavaBaby Membro desde: 21/07/2009 12:43:00 Mensagens: 77 Offline

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.

JavaBaby Membro desde: 21/07/2009 12:43:00 Mensagens: 77 Offline

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...

magnomp wrote: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...

Entendi...e quais ferramentas vc utiliza para desenvolver esta técnica ? Você chega a testes funcionais ou apenas realiza testes de unidade ?

JavaBaby Membro desde: 21/07/2009 12:43:00 Mensagens: 77 Offline

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

JavaChild Membro desde: 03/09/2010 10:44:54 Mensagens: 111 Offline

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.

magnomp wrote: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

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

Virtual Machine Man Membro desde: 07/03/2007 15:58:16 Mensagens: 518 Offline

O problema que voce esta descrevendo deve estar sendo causado por uma dessas situacoes:

1) Voce esta escrevendo testes redundantes, testando a mesma coisa num codigo ja implementado.

2) 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.

YvGa wrote:O problema que voce esta descrevendo deve estar sendo causado por uma dessas situacoes:

1) Voce esta escrevendo testes redundantes, testando a mesma coisa num codigo ja implementado.

2) 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.

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!!

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