Perdendo o medo de mudar

Hoje em dia é cada vez mais difícil fazer um sistema do zero. É sempre necessário realizar integrações com outros sistemas da
empresa, de fornecedores, do governo e, principalmente, sistemas legados. Ainda que pareça absurdo, atualmente a maioria dos
projetos não trabalha com testes unitários. Concordo que nem sempre
será possível trabalhar com testes unitários porque as vezes você não
tem o que testar, ou a lógica está em outra aplicação/camada/tecnologia,
ou o tempo para realizar versus o beneficio não se paga.

Qualquer linguagem OO moderna tem bons frameworks de testes unitários,
falando de Java e .NET existem vários, mas mesmo assim existem muitos e
muitos sistemas feitos sem testes unitários. Não usar este nível de
testes, além da perda da regressão (falando de unidade), traz outros
problemas.

O medo de mudar o código

Acredito que o ponto seja este
mesmo. No final das contas os desenvolvedores ficam com medo,
literalmente. Logo, acabam tomando decisões erradas em termos de
gerência de configuração, criando branches em demasia com medo de
quebrar o código. Essas decisões erradas geradas pelo medo também
afetam a arquitetura, porque ninguém quer evoluir versão de nada com
medo de que as coisas parem de funcionar e, por fim, atacam o design e a
implementação da aplicação. O Design sofre muito, porque as
pessoas param de fazer refactoring ou até mesmo design incremental por não saberem o impacto das mudanças na aplicação, aí não podem garantir
se aquela mudança afetou ou não o resto.

Quando não existem casos de testes, ou um plano de testes, o desenvolvedor fica sem saber ao certo o
que deveria testar e como poderia  proceder com este teste, mesmo que
ele existisse.

Falando dos testes funcionais, o problema é o
custo, sem falar que ele envolve outros recursos,
como um analista de testes e um testador, logo, é mais custoso e demora
mais.

O problema em questão não é
trabalhar com plano de testes, casos de testes e testadores. De fato o
que complica as coisas é o medo de realizar mudanças, de
fazer refactoring e de colocar interfaces onde não existiam, de alterar a
visibilidade de métodos e de modificar classes que não foram feitas pelo desenvolvedor.

Testes unitários: mitigando riscos e medo

Quando trabalhamos com testes
unitários, ou seja, quando é viável esta prática e os desenvolvedores
criam seus testes, além de ganharmos a tão sonhada regressão ou testes
de regressão, conseguimos baixar os custos de rodar os testes e
corrigimos os erros mais perto do desenvolvimento, o que é mais barato e
mais rápido.

Logo, é possível rodar esses testes
de forma exaustiva em um servidor de integração contínua, ou até mesmo
pelo desenvolvedor, no momento em que ele quiser. Isso faz com que o
medo de mudanças diminua e o desenvolvedor use práticas adequadas
de gerência de configuração, design, arquitetura e implementação.

No final todos acabam ganhando com o uso dessa prática, pois
além de acabar com o medo de mudar e refatorar, estamos mitigando riscos
e aumentando as chances de sucesso do projeto.

Os testes unitários e outras boas práticas

Quando começamos a utilizar testes unitários as boas práticas de
desenvolvimento e design começam a pensar em uma coisa chamada Testabilidade. Ao iniciar com testes unitários, você verá que nem todo o código
é testável, logo, você vai começar a se preocupar e criar códigos que sejam testáveis e isso acaba puxando boas práticas como Inversão de
Dependências, Programação Para Interfaces, Programação Defensiva,
Injeção de Dependências e outras práticas de design e implementação.

Cuidando da cultura

Se hoje em dia existem diversas soluções em termos de frameworks para
testes unitários e a utilização destes frameworks é fácil, qual o grande
motivo que leva as pessoas a não aderirem a esta prática? Cultura. Essa
cultura pode ser tanto de desconhecimento das práticas de testes ou até
mesmo dos males que a falta de testes unitários geram em uma aplicação,
tais como medo e riscos.

Então antes de começar a escolher a sua solução de testes unitários e
aprender técnicas de testes, recomendo começar a trabalhar a cultura da
sua empresa, da sua equipe e das pessoas, tanto desenvolvedores como
testadores.

Abraços e até a próxima.