"Implementação óbvia" do TDD significa código primeiro, teste depois?

Meu amigo e eu somos um TDD relativamente novo e temos uma disputa sobre a técnica "Implementação óbvia" (de "TDD By Example" de Kent Beck). Meu amigo diz que isso significa que, se a implementação for óbvia, você deve prosseguir e escrevê-la - antes de qualquer teste para esse novo comportamento. E de fato o livro diz:

Como você implementa operações simples? Basta implementá-los.

Além disso:

Às vezes, você tem certeza de que sabe como implementar uma operação. Continue.

Eu acho que o que o autor quer dizer é que você deve testar primeiro e depois "implementá-lo" - em oposição ao "Fake It ('Till You Make It)" e outras técnicas, que exigem etapas menores no estágio de implementação. Além disso, após essas citações, o autor fala sobre obter "barras vermelhas" (falhas nos testes) ao fazer "Implementação óbvia" - como você pode obter uma barra vermelha sem um teste ?.

No entanto, não consegui encontrar nenhuma citação do livro dizendo "óbvio" ainda significa teste primeiro.

O que você acha? Devemos testar primeiro ou depois quando a implementação é "óbvia" (de acordo com o TDD, é claro)? Você conhece um livro ou post de blog dizendo exatamente isso?

Concordo com a sua interpretação - ainda é o Refator Verde Vermelho, apenas com o bit Refatorado deixado de fora;)

Portanto, escreva primeiro um teste com falha e, em seguida, implemente a solução óbvia, em vez de criar lentamente um design "o mais simples possível".

Você conhece um livro ou post de blog dizendo exatamente isso?

Eu argumentaria que o livro de Beck diz exatamente isso.

Ele continua dizendo

No entanto, usando apenas a implementação óbvia, você está exigindo perfeição de si mesmo. Psicologicamente, isso pode ser um movimento devastador. E se o que você escreve não for realmente a mudança mais simples que poderia passar no teste? E se o seu parceiro lhe mostrar um ainda mais simples? Você é um fracasso! Seu mundo desmorona ao seu redor! Você morre. Você congela.

Como você pode passar no teste escrevendo o código, se ele não existe antes do código?

Obviamente, não há regras rígidas aqui, pois estávamos sendo ágeis, afinal, podemos e devemos nos adaptar à medida que iteramos :)

Em parte, isso dependerá da operação simples e, à medida que você pratica o TDD cada vez mais, regularmente encontra coisas que testou mal ou realmente não testou, tudo isso faz parte da curva de aprendizado.

Além disso, não se esqueça que o TDD permite testar a interface e a implementação antes de confirmar o código ativo.

Você pode saber como implementar alguma coisa, mas com que freqüência escreve uma classe / método perfeito etc. pela primeira vez sem alguns ajustes ao longo do caminho ou percorre o código uma ou duas vezes e seis meses depois, quando altera algo, pode fazê-lo com mais confiança e novamente na caixa de areia dos testes.

Obviamente, os testes não significam que você escreva o código mais corretamente na primeira vez, mas suas alterações são conduzidas pelo teste e os testes se tornam o primeiro cliente do código e, como os testes são muito baratos e, mais importante, sem risco de alteração você tem mais confiança e liberdade enquanto se desenvolve.

Se você está realmente tentando obter uma boa cobertura e uma qualidade mais alta, erre ao lado de mais testes, à medida que pratica o TDD cada vez mais, desenvolvendo seu próprio senso do nível de cobertura necessário.

Aprendi que, para um código trivial, não deve haver nenhum tipo de unittest.

exemplo: se você tiver um método java getter / setter que mapeie um método para uma variável local, um unittest para isso seria um exagero.

pode ser isso que o autor quer dizer com

> "How do you implement simple operations? Just implement them."
> "Sometimes you are sure you know how to implement an operation. Go ahead."