A técnica de Test Driven Development (TDD) define um ciclo (red-green-refactor) que deve ser seguido quando se começa a desenvolver utilizando TDD. Alguns como no post do Vinícius Quaiato diz que:
Escreva um teste que falhe, na verdade um teste que nem compila (vermelho). Escreva um código que compile e faça o teste passar (verde), mesmo que seja um código ruim. Então, após o teste passar melhoramos o código, com a finalidade de deixá-lo mais claro, coeso e simples (refactoring).
Recentemente no Code Better, o Ian Cooper escreveu dizendo que a fase "vermelha" do principal ciclo do TDD não significa código sem compilar e que o código do testes é tão importante quanto o código de produção:
Nós entendemos que devemos escrever um teste antes de escrever o código, mas não podemos escrever um teste antes de escrever o código de teste...nós dizemos que escrevemos um teste antes de escrever qualquer código de produção. Portanto, nosso código de testes é tão valioso quanto o código de produção, por isso nós precisamos escrever com exatidão também.
Ele diz que os quatro modelos da fase de testes (setup, prática, verificação e teardown) dizem que:
As quatros fases do modelo de testes e arrange-act-assert pattern dizem a mesma coisa - coloque o sistema em um estado conhecido, praticar as mudanças que nós estamos testando, e verificar o novo estado da aplicação. Então fazendo um stubbing da operação antes do teste para colocar a aplicação em uma estado inválido, nós podemos garantir que nosso testes falhará. Esta verificação do próprio teste faz a barra ficar vermelha em nosso Test Runner. Esse é o verdadeiro significado de "vermelho" para este passo.
Dessa maneira pode-se garantir de maneira simples que o teste está bem escrito, e que o código também. Se está difícil fazer seu teste primeiro ficar vermelho, segundo Ian é porque existe alguma coisa nele:
Testes que tem lógica condicional, por exemplo, são testes ruins - você deveria saber o que seus testes estão fazendo. Obtendo o passo "vermelho" facilmente é em geral um bom indicador de que nós estamos de fato testando uma unidade. Se obter o passo "vermelho" é díficil, existe provavelmente um problema de arquitetura.
Quando fica díficil obter o passo vermelho quando utiliza-se TDD as pessoas são tentadas a deixar essa fase de lado, o que faz sentido para alguns. O Jonas Abreu falou exatamente sobre isso no blog Vida Geek. Ele diz que algum tempo deixou de seguir os passos como o TDD propõe, e explica:
O que aconteceu foi que eu tinha muito problema para pensar nas unidades pequenas sem ter as unidades grandes. Ah? Basicamente eu não consigo pensar em como implementar sem estar resolvendo o problema.
Jonas se diz ciente das perdas que não usar o ciclo do TDD pode causar:
Talvez eu tenha perdido um pouco na qualidade do código usando essa abordagem top-down, mas ganho bastante em termos de usabilidade desse código. Isso me força a pensar em primeiro lugar em como vai ser usada a funcionalidade final e não nos menores constituintes dela.
Ian tem uma opinião um pouco diferente:
Existe uma tentação para pular a fase vermelha e ir diretamente para a verde. O risco aqui é que você pode ter um falso positivo - seu teste passaria sempre.
Você segue a risca os ciclos do TDD? Acha que às vezes pode ser inevitável deixá-los de lado?