Faz total sentido falar de testes de unidade em um blog focado em teste de software, ainda mais quando se está escrevendo uma série sobre código limpo. Portanto, este será o assunto de hoje em: Insights de código limpo.
No capítulo 9 de Código Limpo – Habilidades práticas do agile software, tio Bob explica como código limpo e testes de unidade se relacionam e explica que código de teste é tão importante como código de produção.
Brevemente, irei passar pelos sub-itens deste capítulo:
As três leis do TDD:
- Você não pode escrever código de produção até ter escrito um teste de unidade que esteja falhando.
- Você não pode escrever mais testes de unidade do que o suficiente para fazê-los falhar, e não compilar também é falhar.
- Você não pode escrever mais código de produção do que o suficiente para passar em um teste falhando.
Mantenha os testes limpos:
Código de teste é tão importante como código de produção e exige pensamento, design de código e cuidado.
Os testes possibilitam as -bilidades (flexibilidade, manutenabilidade e reusabilidade):
Testes de unidade mantém o código flexível, manutenível e reutilizável.
Testes limpos:
Para se garantir testes limpos deve-se garantir a legibilidade dos testes, portanto, estes devem ser claros, simples e com densidade de expressão, em outras palavras, em um teste você quer dizer muito com o mínimo de expressões possíveis.
Linguagem-específica de domínio de testes (Domain-specific testing language):
São linguagens de teste que os programadores utilizam para ajudá-los na escrita de seus testes e para ajudar àqueles que virão a ler os testes no futuro.
Um padrão duplo (A dual standard):
Esta parte trata de diferenças de padrões que podem facilitar a escrita de testes com relação à código de produção. Ressaltasse aqui que haverão coisas que você fará normalmente em um ambiente de testes mas nunca fará no ambiente de produção, mas isso não envolve questões de limpeza, ou seja, tanto código de teste quanto código de produção ambos devem ser limpos.
Um Assert por teste Vs. um único conceito por teste:
Neste sub-capítulo do livro fica claro que mais do que seguir a regra de um assert por teste à risca, deve-se pensar em código limpo, e que portanto, a melhor coisa a dizer é que o número de asserts em testes deve ser minimizado, talvez uma regra melhor seja: que queremos testar um único conceito em cada função de teste. Aqui podemos pensar em testes de comportamento.
F.I.R.S.T.:
Fast (rápido): Os testes devem ser executados rapidamente para prover feedback o quanto antes ao time, e quando estes são lentos, acabam sendo deixados de lado.
Independent (independente): Um teste não pode depender de outro, senão a falha em um teste pode acarretar em diversos outros testes falhando erroneamente e causando uma impressão errada ao time
Repeatable (repetível): O mesmo teste que é executado em ambiente local deve poder ser executado em diferentes tipos de ambiente, como integração, QA, homologação e produção.
Self-validating (auto-verificável): Testes ou passam ou falham. True ou False, simples assim.
Timely (oportuno/feito a tempo): Os testes de unidade devem ser escritos um pouco antes do código de produção que o faz passar. Aplicações devem ser projetadas para facilitar a testabilidade.
Conclusão:
Os testes preservam e melhoram a flexibilidade, manutenabilidade e reusabilidade do código de produção.
E…
Se você deixar seus testes apodrecerem, seu código de produção apodrecerá junto, portanto, mantenha seus testes limpos.
Por fim, gostaria de agradecer a ajuda do Dionatan Moura pela revisão.
=)
E até a semana que vem!
TALKING ABOUT TESTING 