Faça o curso: jQuery na Prática

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.