Nertec

Introdução

Bom, se você chegou até aqui, eu fico feliz, e te dou os parabéns. Escrever testes é um passo importante, e acredito que agrega muito para o desenvolvedor. Você sentira orgulho de si, quando estiver praticando testes no dia a dia. Não só você, mas seus líderes e colegas.

Em uma breve introdução a testes, eu digo que temos prós e contras, mas eu acho que ficar discutindo sobre isso não leva a lugar nenhum, pelo contrário, decidir não implementar testes baseados nos contras é um grande desserviço, ao seu trabalho e ao produto em que você trabalha.

Barganhas

Mas vamos lá, os pontos apresentados a seguir são pessoais e baseados na minha experiência com a escrita de testes em projetos em produção.

Prós
- Agilidade no desenvolvimento;
- Redução do tempo ao estender, refatorar ou remover funcionalidades;
- Resolução de bugs: simulando os comportamentos via teste e depois solucionando;
- Redução de bugs mapeando os cenários/comportamentos nas asserções;
- Criação de algoritmos mais coesos, coerentes e concisos, sem exagero ou trechos desnecessários;
- Documentação das funcionalidades e comportamentos;
- Tornar o sistema mais resiliente;
Contras
- Custo (dependendo do projeto e tipo de teste, no caso um teste e2e é mais caro);
- Complexidade: devido o ambiente ou forma como as coisas foram criadas;
- Curva de aprendizagem (testes podem ser desafiadores e inibidores de início);
- Falta de incentivo: ao pegar projetos sem testes, pode ser complicado configurar o ambiente e começar a implementar;

Os prós e contras podem ser subjetivos e baseados em experiência, mas fui bem sincero sobre o que penso.

E se você já ouviu falar sobre testes, ou já testou antes, deve estar se perguntando porque não coloquei nos contras o que todos sempre falam, que os testes “São demorados e atrasam as tarefas”.

Eu não coloquei isso, porque eu não acredito nessa fala. Para mim, se os testes reduzem bugs e me ajudam a refatorar um código já escrito, eles não fazem com que eu demore para implementar, é um processo natural e necessário durante o ciclo de desenvolvimento.

Se contabilizar o tempo que perde resolvendo um bug que passou pela esteira e foi para produção, junto com a dor de cabeça e talvez a despesa que o bug causou, vai ser bem maior que o tempo de implementação.

Além da correria para resolver um bug crítico que foi para o ambiente de produção, e agora precisa ser resolvido em tempo recorde.

E o “Custo” que mencionei nos contras, é sobre testes que demoram para rodar demandando ambientes específicos, ou que precisam de profissionais especializados para desenvolver (um Tester Engineer por ex.), ou outros (veja mais sobre isso na pirâmide de testes).

Tipos de Testes

Já aproveitando o assunto, vou falar rapidamente sobre a pirâmide de testes.

agile testing pyramid onpath testing QA.png

Referência da imagem: https://www.onpathtesting.com/blog/qa-testers-what-is-the-agile-testing-pyramid

Como podemos ver na imagem, temos vários tipos de testes.

E para simplificar a interpretação, vamos ler a pirâmide de baixo para cima, onde na base temos os testes mais amplos que são mais baratos, como os testes de Unidade e de Componentes. Logo depois vem os testes de Integração, por fim temos testes de API, UI (End to End ou e2e) e os testes exploratórios manuais que são os mais caros.

Eu acredito que no dia a dia, para garantir qualidade e alcançar os pontos destacados nos “Prós” temos que ir até os testes de Integração.
Os outros testes: End to End e Exploratórios, precisam de mais tempo/investimento para serem realizados de modo satisfatório.

Dicionário

Termos técnicos, jargões, nomes de ferramentas, abreviações, etc

Todo assunto tem suas peculiaridades, e testes é mais um. Temos muitos termos com asserts ou testbed ou mock ou stub, mas ainda bem que são apenas termos simples para definir alguns elementos ou ferramentas, então vamos conhecer mais sobre:

Test Runner: é um executor de testes, algumas bibliotecas famosas como: Jest, Jasmine, Mocha, Karma, Ava, etc.
Test Framework: é uma ferramenta que simplifica a escrita de testes, como o Jest, Cypress, Jasmine;
Assertion Library: é uma ferramenta que estende as asserções como exemplo o Chai que se integra ao Mocha para oferecer um pacote que permite testar e executar;
Test Plugin: são plugins para ferramentas de teste que estendem funcionalidades, como o Sinon que permite fazer mocks, stubs e fake servers no Chai;
Test Tools: esse é um termo mais genérico, para ferramentas tipo a VTL (Vue Testing Library) ou a RTL (React Testing Library) que não são apenas ferramentas de asserção ou plugins. Mas sim várias ferramentas que são escritas no topo do DOM Testing Library para enriquecer testes dentro dos frameworks de teste (como o Jest e outros);
JEST: é uma biblioteca e executor de testes, ela oferece ferramentas, que você pode ver no próximo artigo, para simplificar os testes, além de oferecer um ambiente de execução simplificado, o famoso Test Runner;
VITEST: semelhante ao Jest, é um framework para execução de testes;
VTL e RTL (Vue/React testing Library): são ferramentas de testes que compõem executores e frameworks de testes, elas permitem que sejam feitos testes de unidade que evitam tocar na implementação, fazendo assim com que os testes se assemelhem a interação da pessoa que irá usar o produto;
Mock: são imitações ou unidades falsas que simulam o comportamento de unidades reais (fonte: https://www.alura.com.br/artigos/testes-com-mocks-e-stubs?gclid=CjwKCAjwtIaVBhBkEiwAsr7-cypKbacCLN9FSlU3_Cy2wRioHDTQOC-y21pAxWF5Bz-oPZ8vo-2-xhoCB2IQAvD_BwE)
Stub: é um tipo de mock mais simples, sem muitos detalhes de implementação ou que não precisa retornar um valor real, mas apenas algo aproximado que sirva de comparação. Normalmente quando você precisa simular um componente falso (que não tem lógica) e aí você cria um `Stub` com uma `div` e sem muito detalhe, mas que receba props e as declare na view (em um exemplo bem simplista);
Fake Server: é quando você cria um servidor de dados falso para usar em testes de integração mockados (que não acessam diretamente o servidor via HTTPS fora do local);
Spy: é quando você fica espiando um elemento para saber se ele foi executado, em geral, usado com funções e classes (e acredito que apenas com elas);
Data Test ID: é um atributo de elementos HTML que identifica um elemento para ser obtido através de uma ferramenta de testes, facilitando assim a query do elemento quando ele não tem alguma outra forma mais fácil de ser identificado. Evitar ao máximo, e use somente quando não tiver outra opção, pois ele suja a view, deixando o HTML verboso e difícil de debugar pela aba de elementos do DevTools do Navegador.
Skip: pular um teste colocando .skip no método test() assim: test.skip()
Focus ou Only: rodar apenas um teste colocando .only no método test() assim: test.only()

Próximos passos, literatura de testes

Introdução

Barganhas

Tipos de Testes

Dicionário

Termos técnicos, jargões, nomes de ferramentas, abreviações, etc

Links úteis