"Thiago Brito - Os Testes Realmente Diminuem A Velocidade No Desenvolvimento?"
Os testes realmente diminuem a velocidade no desenvolvimento?
Frases como "Fiz sem testes para entregar mais rápido" ou "Está tudo pronto, só falta fazer os Unit Tests". Podem mostrar um terrível engano no seu time!
Você está em uma reunião em pé conversando sobre o desenvolvimento de uma nova funcionalidade e um dos desenvolvedores informa que a parte dele já está pronta, faltando apenas fazer os testes. Você pergunta quais testes ele está trabalhando e ele responde que faltam ainda fazer os Unit Tests.
Um código sem Unit Tests jamais poderá ser considerado pronto. O que faz aumentar ou reduzir a velocidade do desenvolvimento é justamente a forma como você desenvolve o seu código.
A execução de um teste, faz com que seu código seja exercitado de forma automatizada e garante que os mesmos estão tendo resultados consistentes. Testes apropriados, indicam se as mudanças feitas te deixaram mais próximo de concluir o seu objetivo ou não.
Criar Unit Test é a forma mais rápida de automatizar o trabalho chato de entender o que está acontecendo quando algo dá errado e saber que tudo está funcionando logo depois das alterações que acabaram de ser feitas.
É importante que seus Unit Tests sejam rápidos e seus resultados consistentes, ou seja, testes que quebram devido a conexão com o banco de dados que caiu só trazem frustração e causam a desconfiança nos testes. Além de deixar eles lentos.
Acreditar que o tempo de desenvolvimento ao criar Unit Tests é maior do que quando o desenvolvedor não cria testes ou deixa pra fazer depois é um dos maiores erros.
Só o tempo de debug do código, em que ficamos analisando se a função fez o trabalho correto para identificar se houve nenhum efeito colateral com as mudanças que acabamos de fazer é significativamente maior do que o tempo de criação e execução dos Unit Tests.
A falsa idéia de velocidade inicial, pode ser percebida quando são feitas alterações na integração de diversas funções no sistema, ou quando a parte alterada é integrada em diversas do mesmo. Vai compensar testar manualmente todas as possibilidades de erros, não apenas em seu código, mas também nos outros em volta?
Quando seu time estiver reunido e você ouvir aquela frase "Fiz sem testes para entregar mais rápido". Talvez seja a hora de corrigir ele dizendo "Fiz sem testes para gastar mais tempo".