Skip to content

Comece a testar seu código da forma certa

Qual é a forma certa de começar a testar um código? Será que existe práticas que podemos aderir para não começar errado e assim explodir de problemas?

Na ultima semana eu dei um treinamento na DB1 Global, uma empresa situada em Maringá, com projetos pelo Brasil todo. Atualmente estou trabalhando (por enquanto) nela em um projeto de grande porte para o cliente SENAC. Mas o que eu sempre vejo em treinamentos quando se fala sobre teste de código é… Qual a forma certa de começar? Por isso no artigo de hoje vou tentar resumir em como você começa a testar seu código da forma certa.

Quando eu comecei com testes, e confesso que não foi fácil, eu também tinha essa duvida, porem os meus testes ficavam bagunçados e era um parto depois para fazer manutenção. Eu ficava puto comigo mesmo e pensava aonde eu chegaria com isso, já que mais sofria do que tinha alegria.

No projeto que eu comecei a ver teste de código, somente começaram para dizer que os devs sabiam codar o que estava na “moda” (Só para deixar claro que a moda não acabou). Ou seja, por ai você já tem uma base como ficou esse código. Ninguém começou testes por que era importante para o projeto, por que trazia benefícios. Era por que estava na moda e muita gente não sabia, muito menos o GP da empresa. Então a primeira boa prática que eu escrevo aqui é:

#1 – Não faça testes somente para sair no relatório da empresa. 

Porra! Se você quer fuder o projeto, faça outras coisas. Vá jogar PUBG e não entregue a funcionalidade, mas colocar testes no código somente para ficar bonito na fita ou para agradar o cliente por que ele pede. Não faça! Escrever testes só por escrever cria mais bagunça do que ajuda. É um parto para mudar código e você vai deixar os próximos devs xingando você até a sua sexta geração.

Beleza, sabemos que você quer escrever testes por que você acredita e por que você quer estar seguro, a próxima dica que eu dou é:

#2 – Comece pelos testes de unidade

Você não sabe o que é teste de unidade, integração e E2E? Um resumo rápido é:

  • Integração é quando você testa mundo externo ao seu código, ou seja, quando você testa o seu código e um banco de dados. Isso é chamado integração. Isso por que o banco de dados não faz parte do seu código. Você está testando seu código junto com a API do Correios para buscar um endereço? Também é teste de integração. Fechou?
  • E2E, End to end, esse é o teste mais complexo e caro, isso por que você vai testar o sistema de cabo a rabo, essa é a melhor definição que eu encontrei, mas por que? Com esse teste, você simula o comportamento do usuário, insere textos nos inputs e o sistema faz toda a requisição necessária até ter a resposta. Para esse tipo de teste existe ferramentas bem legais como o Protactor e o TesteCafe.
  • Teste de unidade, onde você testa uma pequena unidade do sistema, normalmente uma classe e seus métodos. Testando essa pequena “caixa” do sistema, você garante que aquela parte está certa. Assim quando estivermos testando outras unidades você chega a conclusão que todo o comportamento do sistema está de acordo com os critérios de aceite da funcionalidade. Esse teste é o mais barato e também é o mais rápido.

Seus sistemas podem não ter teste de integração, teste E2E, mas devem ter testes de unidade, mas por que? Quando se faz teste de unidade, implicitamente, seu código passar a ser mais legível, pequeno, com baixo acoplamento e coeso. Abaixo vou tentar explicar o por que disso.  Neste artigo as boas práticas são para o teste de unidade.

#3 – De nome aos bois.

Beleza, vamos agora fazer um teste de unidade, ai vem o segundo teste, terceiro e sua classe de teste é finalizada com 6 testes de unidade para uma classe de negócio.

No final o que vemos é: Teste1(), Teste2() e …

Porra! Quer fuder o projeto novamente?

Vamos dar nomes melhores, nomes condizentes com o que o teste faz. Por exemplo, digamos que você esteja validando que o nome de uma pessoa deve ter o nome completo, ou seja, ninguém tem o nome completo com somente José, ou Maria. Pelo menos deve ter um sobrenome, José do que? Maria de que?

Com isso podemos criar um teste onde seu nome é DeveObrigarNomeDaPessoaParaTerSobrenome(), é um exemplo. Quando esse teste falhar mais tarde você sabe o que falhou e por que falhou, e não que o Teste33() falhou. Ta entendendo melhor agora?

Não se esqueça que o nome tem que dizer exatamente o que você vai testar. Antes de criar um teste pense, o que eu estou testando?

#4 – AAA

Arrange, Act e Asserting, já viu isso?

Basicamente um teste deve ter a Organização, Ação e Atestar se aquilo está de acordo com o esperado. No código abaixo eu mostro um exemplo:

public void DeveSomarDoisNumeros()
{
//Arrange
var calculadora = new Calculadora();

//Act
var resultado = calculadora.Soma(5, 5);

//Assert
Assert.Equals(10, resultado);
}

Você compreendeu melhor? Viu que entre cada “A” existe uma linha em branco? Isso é para deixar evidente o que você está fazendo, Act, e o que está testando, Asserting. O dev que ver aquele código sabe como você chegou nele e com uma leitura simples. Ninguém merece ler código de teste que está bagunçado, com certeza você vai passar mais tempo entendendo do que a manutenção propriamente dita.

Aqui estamos falando sobre a qualidade do teste. Já vi dev falando que teste bom é aquele que passa e o resto agente refatora no código de produção. Sinto em dizer, mas código de teste também é código do sistema, ou código de produção. Se você não tiver carinho com o código de teste, seu código de produção também vai ser um lixo. Sério, vai por min!

#4 – Evite números mágicos

O que são números mágicos? Viu o código anterior, viu os números 5 e 10, aquilo é considerado números mágicos por que não se sabem para que servem e apenas estão lá.

Criar números mágicos é perigos, tudo bem que no exemplo anterior é bem fácil de entender, mas em um exemplo mais complexo você não entender o que é o 5 e o 10. Abaixo re-faço o exemplo anterior sem os números mágicos.

public void DeveSomarDoisNumeros()
{
//Arrange
const int resultadoDaSomaEsperada = 10
const int numero1 = 5;
const int numero2 = 5
var calculadora = new Calculadora();

//Act
var resultado = calculadora.Soma(numero1 , numero2);

//Assert
Assert.Equals(resultadoDaSomaEsperada , resultado);
}

Ficou bem melhor agora né? Alguém pode falar, mas o código cresceu e eu falo sim, o código cresceu e a explicação também melhorou.

Bom, essas são as formas certas na qual você pode começar a ter um bom código de teste.

Mas o que de fato você ganha com isso?

#Documentação

Toda vez que você faz um teste, nomeia e atesta ele da forma certa, você está documentando isso, deixando claro um comportamento que o software deve ter. Mas tarde quando outro dev entrar na equipe ele saberá como aquele comportamento funciona.

#Qualidade de Código

Quando você testa, você implicitamente está fazendo código de qualidade. Isso acontece por que para seu código permitir ser testado ele tem que ter no mínimo padrões que levem a isso, um dos padrões é um código coeso e com baixo acoplamento. Se seu código utilizar dependências e o mesmo não é uma abstração, você já não consegue testar.

Muitos autores falam que só de criar o teste do código aquele código é uma certeza de ter o minimo desejado para um código de qualidade.

#Segurança nas alterações

Essa semana precisei alterar um código já existente para poder atender a um requisito, basicamente mudamos um modulo de cabeça para baixo onde uma classe deixou de ser a principal para ser uma coadjuvante com outros filhos. Só isso deu um puta trabalho. No fim, antes de ir para o teste funcional, estávamos seguro que tudo estava funcionando pois nossos testes de unidade estavam todos OK.

#Confiança

Esse eu acho que depois da documentação é o principal, pois você pode subir seus códigos para produção sem medo. Bugs ainda vão existir? Claro que sim, mas isso diminui em muito quando você automatiza seus testes principalmente para uma entrega continua.

Bom galera, espero ter passado tudo o que seria de legal para começar a testar seu código da forma certa. Espero no próximo artigo mostrar outras boas praticas para testes.

Você gostou desse artigo? Gostaria de saber mais sobre Testes? Eu desenvolvi um curso na Udemy, preço camarada. Acesse https://www.udemy.com/automatizando-testes-para-sua-aplicacao

Published inTestes

Be First to Comment

Deixe uma resposta

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