BT

Vermelho no TDD não significa código sem compilar

por Lucas Souza em 26 Mar 2010 |

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?

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

Abordagem top-down by Luiz Fernando Oliveira Corte R...

Como escrevi no comentário do post do Jonas, também sou a favor da abordagem que ele toma. Mas não acho que ela quebre o ciclo TDD. Você também começa com vermelho: você escreve um teste genérico, para uma classe no topo da hierarquia de chamadas, e ele não vai passar. Então você escreve outro teste, dessa vez para uma classe mais embaixo na hierarquia, e ele também não vai passar. Então você faz esse último teste passar e repete esse procedimento até o teste que você escreveu primeiro passar.

Sobre o código compilar by Vinicius Quaiato

Aproveitando que eu fui citado no primeiro parágrafo.
Eu desenvolvo em C#, desta forma muitos dos testes que eu escrevo utilizando Test-First acabam não compilando. Alguns podem entender isso como válido, a verdade é que não consigo obter um RED, pois nem consigo executar os testes se o projeto não compila.

É claro que o teste é tão importante quanto o código de produção, senão não há sentido para este teste existir. Ele deve fazer sentido, deve funcionar, deve realmente garantir algo importante ao sistema/negócio.

O ponto que acho importante de escrever um teste que falha é o fato de que você sabe realmente aonde está indo. Escrevendo testes que funcionam não garantem que seu sistema funciona, apenas garante que uma situação funciona, talvez a situação mais trivial.

Att,
Vinicius Quaiato
viniciusquaiato.com

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

2 Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2014 C4Media Inc.
Política de privacidade
BT