Por que os testes automatizados são tão importantes?

A única forma segura que temos para garantir que o código que estamos escrevendo funciona, e vai continuar funcionando, é por meio de testes automatizados.

Basicamente, um teste automatizado é composto por um conjunto de entradas seguido pela execução de algum comportamento e a verificação da saída ou do estado dos dados após a execução desse comportamento.

test("Deve criar a conta de um passageiro", async function () {
	const input = {
		name: "John Doe",
		email: `john.doe${Math.random()}@gmail.com`,
		cpf: "97456321558",
		isPassenger: true
	};
	const outputSignup = await signup.execute(input);
	expect(outputSignup.accountId).toBeDefined();
	const outputGetAccount = await getAccount.execute(outputSignup.accountId);
	expect(outputGetAccount.getName()).toBe(input.name);
	expect(outputGetAccount.getEmail()).toBe(input.email);
	expect(outputGetAccount.getCpf()).toBe(input.cpf);
	expect(outputGetAccount.isPassenger).toBe(input.isPassenger);
});

Isso é exatamente o que fazemos de forma manual quando navegamos em telas, preenchemos os campos de um formulário e clicamos em botões, só que você transfere as ações antes realizadas com as suas mãos e verificadas com seus olhos para o código. O mais importante é que esse conjunto de ações poderá ser executado, de forma rápida, tantas vezes quanto for necessário.

Alias, essa última etapa, de verificação, é fundamental.

Muitas vezes criamos testes que apenas aumentam a cobertura mas não verificam se o resultado da execução do comportamento estava realmente correto.

Sem isso, é possível que defeitos se acumulem, mesmo com as linhas devidamente testadas, por isso, cuidado ao analisar o percentual de cobertura, ele é muito relativo, dê o máximo de atenção para as verificações e o quanto elas conseguem garantir que o comportamento executado está realmente correto.

Ah, mas eu já faço os testes de forma manual, porque isso não é suficiente?

Por um único motivo, o código que você escreveu e testou manualmente hoje provavelmente vai mudar ou vai ser impactado por mudanças amanhã e boa parte dos testes manuais vão precisar ser feitos novamente e esse é o principal problema, testar manualmente o tempo todo tudo aquilo que deveria ser testado não é viável diversos motivos:

• Um teste automatizado, de unidade, roda em poucos milissegundos, um teste mais complexo, de integração ou E2E pode levar alguns segundos. Enquanto isso, um teste manual dificilmente é feito em menos de alguns minutos. Ou seja, enquanto uma pessoa faz meia dúzia de testes manuais é possível executar centenas de testes automatizados
• O volume de linhas de código aumenta todos os dias e seria necessário fazer uma quantidade cada vez maior de testes manuais para garantir que tanto o código novo quanto as modificações feitas no código antigo continuam funcionando, é como uma bola de neve
• Enquanto estamos escrevendo o código sabemos exatamente o que precisa ser testado mas depois de alguns dias já não lembramos mais de tantos detalhes, os testes automatizados registram exatamente esses detalhes que depois provavelmente seriam esquecidos nos testes manuais
• Pessoas diferentes mexem nas mesmas linhas de código o tempo todo, fazendo com que seja muito difícil executar os testes manuais com a mesma consistência
• Testar manualmente torna o ciclo de entregas muito mais longo, já que leva mais tempo para testar tudo manualmente e garantir que está funcionando

Muita gente vai dizer o seguinte: "O importante é entregar" ou "Eu trabalho há 20 anos sem escrever nenhum teste e está tudo funcionando".

O que acaba acontecendo é que a maior parte das pessoas simplesmente assumem o risco, testando manualmente somente aquilo que foi modificado, mas isso causa um fenômeno chamado de regressão, que é quando o código que funcionava deixa de funcionar.

Na maior parte das vezes não percebemos essa regressão e quem acaba descobrindo e ficando insatisfeito é o cliente final. O resultado é que muitas equipes acabam trabalhando mais tempo apenas corrigindo defeitos do que de fato evoluindo o produto.

Antigamente existia menos concorrência, o software não era tão presente na maior parte dos negócios e a tolerância era muito maior. Hoje em dia o prejuízo pode ser muito grande, tanto financeiro, decorrente do impacto dos defeitos e processos judiciais pedindo indenização pelos danos causados, até afetar a imagem da empresa, que perde os clientes muito mais rápido do que consegue conquistar outros.

Adotar testes automatizados não é questão de gosto pessoal ou preferência da equipe, é uma obrigação, é o que vai encurtar o ciclo de desenvolvimento, aumentar a produtividade, reduzir a quantidade de defeitos, proporcionar uma entrega contínua de valor de negócio e permitir que as mudanças necessárias sejam feitas sem tanto impacto.

O tipo de teste, se é de unidade ou integração, pouco importa. Ambos tem a mesma capacidade de garantir que o código que estamos escrevendo funciona e continuará funcionando, isso é o mais importante. É melhor ter um conjunto de testes de integração que dão resultado do que ficar sonhando com testes de unidade que nunca serão feitos.

Por fim, os testes nos dão coragem para refatorar e evoluir o design e a arquitetura da aplicação ao longo do tempo e sem dúvida isso ajuda a melhorar ainda mais a produtividade, reduzir a rotatividade e a satisfação da equipe, afinal, ninguém gosta de trabalhar corrigindo defeitos o tempo todo, esse não é um tipo de trabalho desafiador e que estimula as pessoas a crescerem profissionalmente.

Lembre-se, muitas empresas vão à falência com um código bem feito, mas poucas tem sucesso ao longo do tempo com um código de má qualidade e sem testes, se conseguem é as custas de um ambiente caótico, rotatividade e dinheiro jogado fora.