Image for post
Image for post

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

Danilo Ferreira
Sep 25 · 3 min read

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.

Danilo Ferreira

Blog sobre Danilo Ferreira

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store