A ausência de testes unitários pode indicar falta de maturidade no desenvolvimento

A quantidade de boas práticas que são deixadas de lado em TI pode ser assustadora… Na semana passada, por exemplo, escrevi sobre documentação, um processo que, embora trabalhoso, contém um grande número de benefícios para as equipes de tecnologia.

Aproveitando a reflexão, parei para pensar em outras coisas que deveriam acontecer nos times de tecnologia para assegurar a qualidade de processos e de produtos, mas que geralmente não acontecem. Uma delas me chamou a atenção: a prática recorrente de testes unitários.

Em teoria, os testes unitários deveriam ser realizados pelos desenvolvedores assim que uma função é desenvolvida. Mas o que geralmente se vê é que há certa relutância em desenvolver esses testes. Afinal, por que alguém iria querer criar mais código para testar o que já foi desenvolvido?

Bom, não é difícil entender o porquê. Precisamos, a todo o momento, entregar novas funcionalidades, evoluir fluxos e aprimorar a experiência do cliente, certo? E entregar dentro do prazo, com rapidez, não é mais suficiente. As entregas têm que ter, cada vez mais, qualidade.

Por isso, é inviável negar o papel do teste unitário — que, por si só, garante o funcionamento do código em sua menor fração.

Ou seja, testes unitários são essenciais para testar módulos, métodos, classes, funcionalidades, entre outros, e assegurar que aquela unidade está performando de acordo com o que é esperado dela.

Na minha visão, o teste unitário, assim como qualquer outro teste automatizado, é importante para assegurar que um produto ou funcionalidade vai performar mesmo depois de alguma alteração. É papel dos testes regressivos trazer essa segurança a um time, especialmente em um ambiente em que há tanta pressão para que inovações sejam colocadas em produção.

Se um time de desenvolvimento tem uma rotina para verificar se o código desenvolvido está fazendo o que deveria fazer, então esse time está protegido por uma “camada de segurança” que aumenta a confiança na entrega. Isso evita que um produto apresente falhas e que gere retrabalho.

Outra vantagem? Testes unitários, geralmente, levam segundos para testar toda uma aplicação, mesmo depois que diversas alterações foram feitas nela. Sem falar que, quando comparados aos testes de interface do usuário (que também devem existir, porque são igualmente importantes), eles são bem menos custosos.

Portanto, o cenário que temos quando decidimos levar os testes unitários a sério são várias rotinas de testes isoladas que podem ser executadas inúmeras vezes. Isso permite que anomalias no código sejam rapidamente identificadas e priorizadas para correção, especialmente aquelas que surgem depois de modificações e alterações. É como um sistema de alarmes minucioso que pisca toda vez que algo errado acontece. Parece conveniente, não é?

Vou até mais além. Não acho que testes de unidade sejam simplesmente um processo — eles são, na verdade, parte de uma cultura de qualidade em que o desenvolvedor e o QA trabalham juntos, sem a crença popular de que esses dois papéis estão sempre em guerra.

Na minha visão, os testes unitários e regressivos são componentes imprescindíveis do ágil. E por que? Porque sem isso, não tem progresso. É tentar codificar uma feature, e quebrar um código que funcionava e ninguém consegue rapidamente enteder o motivo.

Em times que prezam pela qualidade acima de tudo, fica claro que os testes unitários estão ali para ajudar na evolução da arquitetura, incentivar a refatoração e construir produtos que não deixem o usuário na mão. Por isso pode ser confuso entender o motivo pelo qual esses testes são deixados de lado com tanta frequência.

Não é incomum ver times de desenvolvimento ignorando a prática quando prazos apertam, ou preferindo que QAs façam testes unitários. Tudo bem que o QA faça um teste unitário aqui ou ali, mas quando falamos de cultura de qualidade, o papel do desenvolvedor é, também, de garantir a qualidade do que ele desenvolve.

Em outras palavras: todo mundo é responsável pela qualidade e o desenvolvedor não é exceção. No entanto, ainda falta maturidade para construir esse mindset na prática. E, enquanto os testes unitários não estiverem sendo feitos com mais frequência, é melhor duvidar que essa maturidade existe.