Perdendo o medo de mudar código

Hoje em dia, cada vez mais e difícil fazer um sistema do zero, sempre é necessário realizar integrações com outros sistemas da empresa, sistemas de fornecedores, sistemas do governo e principalmente sistemas legados. Hoje em dia ainda que pareça absurdo a maioria dos projetos não trabalham com testes unitários, concordo que nem sempre será possível trabalhar com testes unitários por que as vezes você não tem o que testar, ou a lógica esta 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 muito 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) existem outros problemas.



O Medo de mudar o código

Medo de Mudar 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. Estas decisões erradas geradas pelo medo também afetam a arquitetura, por que ninguem quer evoluir versão de nada com medo que as coisas parem de funcionar e por fim atacam o design e a implementação da aplicação.

O Design sobre muito por que as pessoas param de fazer refactoring ou até mesmo design incremental por que não sabem o impacto das mudanças na aplicação e não podem garantir se aquela mudança afetou ou não o resto.

Quando não existem casos de testes bem como um plano de testes o desenvolvedor fica sem saber ao certo o que deveria testar e como poderia  proceder com este teste, mesmo que este teste existisse, falando de testes funcionais, o problema é o custo deste teste, sem falar que este teste 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 facto o que complica as coisas é o medo do pessoal de realizar mudanças, de fazer refactoring e colocar interfaces onde não existiam de alterar a visibilidade de métodos e de modificar classes que não foi o desenvolvedor que fez.

Testes Unitários: Mitigando Riscos e Medo

Alívio

Quando nos 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, nos conseguimos baixar os custos de rodar os testes e corrigimos os erros mais perto do desenvolvimento o que é mais barato e mais rápido também.

Logo é possível rodar estes 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 poça usar práticas adequadas de gerência de configuração, design, arquiteta e implementação.

No final todos acabam ganhando com a utilização desta pratica, 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çar a pensar em uma coisa chamada *Testabilidade* por que 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ódigo que é testável isso acaba puxando boas práticas como a 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 lava as pessoas a não aderir a esta prática? Cultura. Esta 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.