fbpx

Como usar o feedback dos testes unitários para programar melhor

Como usar o feedback dos testes unitários para programar melhor

Já perdi muito tempo tentando entender código mal escrito.

Pior que isso, já perdi muito tempo tentando entender código que eu mesmo escrevi.
Código feito às pressas, desenvolvido sem muita preocupação com o futuro, mesmo sabendo que mais tarde precisaria voltar para dar manutenção ou desenvolver uma nova funcionalidade.

Quando comecei a programar, lá nos primórdios, com uma linguagem que muito provavelmente você nunca ouviu falar, a preocupação com qualidade de código nem passava pela minha cabeça.

Mais tarde, quando tive o primeiro contato com POO, e ouvi falar sobre boas práticas de programação, em vez de abraçar a ideia e me tornar embaixador da causa, a primeira coisa que pensei foi: por quê preciso me preocupar com isso se o que importa é o programa fazer o que o cliente pede?

O argumento até pode fazer sentido para um programador sem experiência. Mas se tem uma coisa que o cliente quer mais do que simplesmente o programa funcione bem, é que ele se adeque rapidamente às mudanças.

Todo programador sabe que regras de negócio mudam o tempo todo, isso não é novidade para ninguém.
Não é fácil aliar adaptabilidade à qualidade, sem que se tenha um ciclo contínuo de melhoria em cada etapa do desenvolvimento do software.

A única maneira de fazer entregas consistentes e dentro do prazo é mantendo o código limpo.

Quando escrevemos testes automatizados, a primeira intenção é evitar que uma funcionalidade nova afete negativamente uma antiga. Além da cobertura de testes garantindo que uma modificação no código não vai fazer o programa funcionar de maneira errada, outros benefícios também surgem:

Simplicidade

Quando iniciamos a implementação escrevendo primeiro o teste que irá testar aquela funcionalidade, somos obrigados a pensar apenas no que a classe deve fazer, e nos faz esquecer por um momento da implementação. Às vezes temos o hábito de pensar em como fazer antes de pensar no que deve ser feito, criando soluções complexas para um problema que poderia ter sido resolvido de forma simples.

Com isso, focamos apenas no código que resolve o problema representado pelo teste de unidade, abrindo mão do código complexo que muitas das vezes escrevemos sem necessidade. Se o cliente nos pedir A, entregamos A e não ABC.

Fornece melhor reflexão sobre o design das classes

No cenário tradicional, muitas das vezes a falta de coesão e o excesso de acoplamento é causado porque desenvolvemos com enfoque apenas na funcionalidade, esquecendo de como ela deve funcionar perante o todo.

Quando o primeiro código que escrevemos é o teste, temos a classe de testes como o primeiro cliente do código de produção. Isso faz com que as classes de produção nasçam desacopladas, com todas as dependências expostas, já que elas precisarão ser injetadas para que você consiga testá-las.

O código nasce limpo

Pensamos sobretudo no nome ideal para a classe, os seus métodos, parâmetros e retorno que realmente revelam o propósito do que está sendo desenvolvido. E mais, o teste nos dá feedback constante que nos torna capazes de identificar com velocidade quando temos problemas de acoplamento e falta de coesão. O código realmente nasce com qualidade.

Essa prática também é conhecida como TDD (Test Driven Development).
O livro Test Driven Development: By Example é uma ótima referência, caso você queira se aprofundar no assunto. Autor conta quais foram as motivações que o levaram a desenvolver a prática do TDD. É um livro que vale a pena ter na estante.

Receba meu conteúdo no Telegram

Se você deseja receber outros conteúdos direto no seu celular, entre no meu canal no Telegram.
Lá eu compartilho dicas para você dominar definitivamente a escrita do código limpo.

Hey,

o que você achou deste conteúdo? Conte nos comentários.

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *