17/1/2021 Roberto Umbelino

Troféu de testes

Fala meus jovens, dessa vez vamos falar um pouco sobre o imenso universo de Testes automatizados, e já de início o tema será Troféu de testes.

Serei bem direto no assunto 😄, então vou partir do ponto em que você já saiba o que são testes automatizados, belezinha? 👍

📑 Sobre

O surgimento do Troféu de testes começou com um tweet simples, porém muito instigante.

O Tweet foi de Guillermo Rauch (Criador do Socket.io e fundador da Vercel), e dizia o seguinte.

Escreva testes. Não muitos. Mas mais de integração.

Isso gerou uma certa confusão na comunidade no sentido de "o que o Guillermo queria dizer com isso?".

E foi então que Kent C. Dodds (referência no mundo em testes automatizados) veio para sanar as dúvidas da comunidade explicando o que Guillermo quis dizer com aquele tweet. E foi então que o Dodds criou o Troféu de testes.

(Surgimento do troféu de testes.)

Agora que já sabemos um pouco da história, vamos a explicação de Dodds e entender o propósito do Troféu de testes.

🤔 Explicando o Tweet

Certo, vamos entender como Dodds explanou a frase de Guillermo, então vamos por partes.

Tweet: Escreva testes. Não muitos. Mas mais de integração.

Escreva testes

Bom, como já sabemos das vantagens de se ter testes automatizados em nossas aplicações, não temos nem o que questionar nessa frase, com certeza devemos escrever testes. 😄

Não muitos

Aqui gera algumas dúvidas, Não muitos? Quanto mais testes não é melhor? 🤔

Dodds explica sobre a busca insaciável que alguns desenvolvedores têm pelo 100% de coverage. (✋ foi mal, eu sou um rsrsrs). Pois então, Dodds explica que atualmente temos Linters e Type Checking para nos auxiliar no desenvolvimento, e essa análise do código já consegue evitar muitos dos possíveis erros bobos que acabaríamos cometendo, e é com esse fato que Kent diz que 70% de cobertura no código já é o suficiente. Muito dos trechos de código que não estão cobertos acabam sendo pequenas coisas fora do fluxo principal, que uma checagem de tipos já pode garantir.

Kent também completa dizendo que devemos focar nos testes relacionado a regra de negócio, pois isso é o mais importante e que traz maior confiabilidade para o produto.

Mais de integração

A Pirâmide de testes nos lembra que devemos escrever mais testes unitários, depois integração e por fim E2E. Dodds explica que o motivo de fazer “mais testes de integração” é porque é nesse teste que existe a regra de negócio, e é testando essas regras da aplicação que se gera uma confiabilidade muito maior do produto.

O teste unitário não consegue entregar isso, pois podemos testar cada unidade e garantir o funcionamento dela, mas não sabemos se ao integrarmos as unidades ainda vão funcionar corretamente em conjunto.

Unidades não provam a eficácia do conjunto.

(Representação de testes unitários.)

E foi assim que surgiu o Troféu de testes.

🏆 Troféu de testes

O Troféu de testes traz um agregado de tipos de testes e conceitos para que a Confiabilidade da aplicação seja muito maior, ou seja, o grande propósito do troféu de testes é que seja possível conseguir um resultado melhor nos testes automatizados da aplicação, gerando muito mais confiança no produto desenvolvido.

O Troféu é muito semelhante a Pirâmide de testes, com a adição de um novo elemento e a reorganização da prioridade dos tipos de testes.

Como pode ser visto na imagem abaixo:

(Imagem representativa do troféu de testes.)

Showww, mas o que são esses carinhas? 🤔

Static

O estático seriam os Linters e Type Checking, que fazem a análise do nosso código, minimizando as chances de possíveis erros.

Unit Test

Os testes unitários têm como finalidade realizar o teste de uma unidade isolada, como uma função, um componente.

⭐ Vamos a um exemplo para ficar mais claro, temos uma função que faz a validação de um email.

isValidEmail('exemplo@gmail.com') // True - Email é válido
isValidEmail('exemplo') // False - Email é inválido

Certo, agora nesse caso o teste unitário serviria para testar essa funcionalidade de forma isolada, passando emails válidos e inválidos e verificando se o retorno está correto.

Integration Test

Diferente da Pirâmide de teste, o teste de integração agora é o principal, e o seu propósito é testar um conjunto de funcionalidades, a junção de módulos. Aqui é um tipo de teste onde entra a regra de negócio do produto/software, testar a regra de negócio traz mais confiança no resultado.

⭐ Exemplo, vamos fazer um cadastro de um Pedido, porém o pedido possui algumas dependências, como Cliente, Transportadora, Condição de pagamento. Nesse caso eu já estaria realizando a integração de 4 módulos.

No teste de integração agora seria possível testar as peculirades/regras do produto, como:

• Não poder cadastrar um Pedido sem um Cliente.
• Utilizar uma Transportadora padrão caso o usuário não informe nenhuma.

Testar que as regras estão funcionando.

E2E Test

O E2E significa End-To-End, isto é, testes de ponta a ponta. No teste E2E devemos simular um ambiente real, um ambiente de produção, onde nada deve ser “mockado”.

⭐ Exemplo, digamos que temos uma API para realizar as operações de um ecommerce, então, a diferença do exemplo anterior de Criar um Pedido, seria que a partir de agora temos que subir essa API e realizar uma requisição para criar um pedido, verificar se o registro foi criado na base de dados e aguardar a resposta do servidor, dessa forma testando a aplicação de ponta a ponta.

🔗 Referências

Você pode estudar uma pouco mais do assunto nos links:

• https://kentcdodds.com/blog/write-tests
• https://medium.com/@sergioamjr91/escreva-testes-n%C3%A3o-muitos-mas-mais-de-integra%C3%A7%C3%A3o-7ebebf225516

“Programadores amam automatizar os processos, inclusive os testes.” 😉

Roberto Umbelino.