A única forma segura que temos para garantir que o código que estamos escrevendo funciona, e vai continuar funcionando, e por meio de testes automatizados.
Basicamente, um teste automatizado e composto por um conjunto de entradas seguido pela execução de algum comportamento e a verificação da saida 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 formulario e clicamos em botoes, so que você transfere as acoes antes realizadas com as suas maos e verificadas com seus olhos para o código. O mais importante e que esse conjunto de acoes podera ser executado, de forma rápida, tantas vezes quanto for necessario.
Alias, essa última etapa, de verificação, e 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, e possível que defeitos se acumulem, mesmo com as linhas devidamente testadas, por isso, cuidado ao analisar o percentual de cobertura, ele e muito relativo, de o maximo de atencao para as verificacoes e o quanto elas conseguem garantir que o comportamento executado esta realmente correto.
Ah, mas eu já faco os testes de forma manual, por que 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 mudancas amanha e boa parte dos testes manuais vao precisar ser feitos novamente e esse e o principal problema, testar manualmente o tempo todo tudo aquilo que deveria ser testado Não é viável por 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 e feito em menos de alguns minutos. Ou seja, enquanto uma pessoa faz meia duzia de testes manuais e possível executar centenas de testes automatizados
- O volume de linhas de código aumenta todos os dias e seria necessario fazer uma quantidade cada vez maior de testes manuais para garantir que tanto o código novo quanto as modificacoes feitas no código antigo continuam funcionando, e 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 consistencia
- Testar manualmente torna o ciclo de entregas muito mais longo, já que leva mais tempo para testar tudo manualmente e garantir que esta funcionando
Muita gente vai dizer o seguinte: "O importante e entregar" ou "Eu trabalho ha 20 anos sem escrever nenhum teste e esta tudo funcionando".
O que acaba acontecendo e que a maior parte das pessoas simplesmente assumem o risco, testando manualmente somente aquilo que foi modificado, mas isso causa um fenomeno chamado de regressao, que e quando o código que funcionava deixa de funcionar.
Na maior parte das vezes não percebemos essa regressao e quem acaba descobrindo e ficando insatisfeito e 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 concorrencia, o software não era tao presente na maior parte dos negocios e a tolerância era muito maior. Hoje em dia o prejuizo pode ser muito grande, tanto financeiro, decorrente do impacto dos defeitos e processos judiciais pedindo indenizacao 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 é questao de gosto pessoal ou preferência da equipe, e uma obrigacao, e o que vai encurtar o ciclo de desenvolvimento, aumentar a produtividade, reduzir a quantidade de defeitos, proporcionar uma entrega continua de valor de negocio e permitir que as mudancas necessarias sejam feitas sem tanto impacto.
O tipo de teste, se e de unidade ou integração, pouco importa. Ambos tem a mesma capacidade de garantir que o código que estamos escrevendo funciona e continuara funcionando, Isso é o mais importante. E melhor ter um conjunto de testes de integração que dao resultado do que ficar sonhando com testes de unidade que nunca serao feitos.
Por fim, os testes nos dao 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 satisfacao 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 vao a falencia com um código bem feito, mas poucas tem sucesso ao longo do tempo com um código de ma qualidade e sem testes, se conseguem e as custas de um ambiente caotico, rotatividade e dinheiro jogado fora.