Atualmente eu trabalho em basicamente duas aplicações: a do Jus Navigandi e o TrendTime. São duas aplicações Ruby On Rails, bem distintas, nessas duas aplicações eu faço testes.

Mas são níveis de testes diferentes, infelizmente. Enquanto que na aplicação do Jus Navigandi eu não escrevo código sem testes, na do TrendTime eu ignoro alguns lugares.

Eu faço isso por um único motivo: No Jus Navigandi o código não é meu, não é uma aplicação minha. Justamente por isso eu não posso arriscar em escrever códigos sem testes, sem ter um mínimo de qualidade aceitável. No TrendTime parte da aplicação foi feita sem testes, só no “olhômetro”. Claro que temos uma suíte de testes, mas ela não cobre a aplicação 100%.

Eu faço isso por quê no TrendTime eu posso errar e voltar atrás, enquanto que na aplicação do Jus Navigandi eu não posso cometer esse mesmo deslize. O código não é meu, o código é do Jus Navigandi, e como o código faz parte da empresa, o código tem que refletir a qualidade que é o Jus Navigandi.

O Jus Navigandi é uma empresa em excelência nos artigos publicados, é uma revista jurídica, como tal não é qualquer texto que entra lá. Existe uma bancada de pessoas que analisa todos os textos no dia a dia e apenas os melhores textos é que são selecionados.

Nós programadores temos que levar essa qualidade para dentro do coração do Jus Navigandi, o código tem que refletir a mesma qualidade com que os textos do Jus Navigandi são aceitos. O código tem que ser bom, o código tem que ser limpo e o código tem que ter testes (ciclo vicioso de qualidade).

Quando eu navego pelo github, por vários projetos, a primeira coisa que eu faço é descer a barra de rolagem e procuro por test ou spec. Faço isso pra saber se o criador daquela biblioteca teve pelo menos o trabalho de fazer alguns testes naquele código. Faço isso porquê eu, como um desenvolvedor que vai usar aquele código, fico mais tranquilo em saber que a biblioteca possui testes. Por conta disso, posso codificar com mais tranquilidade e se alguma coisa acontecer, vou primeiro verificar meus testes/códigos.

Assim como as bibliotecas que eu vou escrever, se eu não fizer os testes, vou passar menos confiança para quem possivelmente vai utiliza-la. Aprendi que na comunidade Ruby On Rails, os testes expressam mais do que os códigos. Se eu quiser saber como uma biblioteca realmente funciona, eu não preciso necessariamente criar algo com aquele código, eu posso ver a suíte de testes e me situar sobre aquela biblioteca.

Em uma empresa que você faz parte do time, é essencial que você passe tranquilidade para os outros programadores, sejam eles pessoas que já trabalhe com você ou um novo programador que vai ajudar o seu time.

Com uma suíte de testes, você tem a oportunidade de mudar tudo, arrumar e deixar como era antes. Por exemplo, mudar de SQL para NoSQL e sua aplicação continuar a mesma.

A melhor forma de você passar confiança para outros programadores é fazendo testes e cobrindo sua aplicação de testes. São eles que vão te salvar no dia que você vai ter que mudar a regra de negócio. São os testes que vão te guiar para uma solução simples.