BT
x Por favor preencha a pesquisa do InfoQ !

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?

Avalie esse artigo

Relevância
Estilo/Redação

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 mensagens 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 mensagens dessa discussão

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

Receber mensagens dessa discussão

2 Dê sua opinião
Feedback geral
Bugs
Publicidade
Editorial
Marketing
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2016 C4Media Inc.
Política de privacidade
BT

Percebemos que você está utilizando um bloqueador de propagandas

Nós entendemos porquê utilizar um bloqueador de propagandas. No entanto, nós precisamos da sua ajuda para manter o InfoQ gratuito. O InfoQ não compartilhará seus dados com nenhum terceiro sem que você autorize. Procuramos trabalhar com anúncios de empresas e produtos que sejam relevantes para nossos leitores. Por favor, considere adicionar o InfoQ como uma exceção no seu bloqueador de propagandas.