- Certificar que o teste falha.
- Os testes executem todos os caminhos possíveis de código.
- Haja confiança total no código.
- Evitar depuração.
- Acelerar mais ainda o desenvolvimento.
Se escrevermos o teste depois, pode haver um problema no teste que o faça passar mesmo que o código testado esteja errado. Uma forma de testarmos o teste é, ao invés de escrever um teste para o teste, ter certeza que o mesmo falha quando a implementação está incorreta.
Se os testes não exercitam cada trecho de código, então este código não testado é legado. O código legado não dá confiança ao programador e é difícil de entender, o que leva ele a usar a depuração (debug). E lembre-se que código não testado é código não documentado, já que os testes são a especificação.
A confiança e o entendimento do código gerado pelo TDD se dão em níveis incomparáveis aos conhecidos fora deste método, vale a pena experimentar. Essa é uma forma de acelerar mais ainda o desenvolvimento com testes, já que escrevendo testes depois você vai perder tempo debugando não apenas o código mas também o teste.
Se os testes não exercitam cada trecho de código, então este código não testado é legado. O código legado não dá confiança ao programador e é difícil de entender, o que leva ele a usar a depuração (debug). E lembre-se que código não testado é código não documentado, já que os testes são a especificação.
A confiança e o entendimento do código gerado pelo TDD se dão em níveis incomparáveis aos conhecidos fora deste método, vale a pena experimentar. Essa é uma forma de acelerar mais ainda o desenvolvimento com testes, já que escrevendo testes depois você vai perder tempo debugando não apenas o código mas também o teste.
Para isso não basta escrever os testes antes do código. Também é necessário que:
- Todo código de produção seja o mais simples possível para fazer passar um teste.
- Os testes e implementações devem ser feitas em passos de bebê.
