A arquitetura de microsserviços descreve a prática de dividir um aplicativo em uma série de componentes menores e mais orientados para a solução de problemas. Em seguida, cada um desses componentes se comunica entre si através de protocolos comuns como HTTP ou o TCP mais leve.
Você pode estar se perguntando – os testes são importantes para mim?
Longa história – SIM.
O teste de software é importante por vários motivos, mas o mais importante:
- Economiza dinheiro e muito tempo
- Segurança
- Qualidade do produto (menos bugs e erros)
- Satisfação do cliente
- Permite dormir em paz à noite
Ninguém gosta de um aplicativo que tenha erros e pare de funcionar sem motivo. E não há necessidade de falar sobre os riscos da falta de segurança, o que permite que os hackers roubem credenciais e até dinheiro.
Desde que você desenvolva um aplicativo que será usado pelos usuários e tenha alguma complexidade, os testes não devem ser uma opção – eles devem ser obrigatórios.
Que teste devo escrever?
Existem vários tipos de teste de software.
Os tipos de teste funcional incluem:
- Teste de Unidade
- Teste de integração
- Teste de fumaça
- Teste de regressão
- Teste de sanidade
- Teste beta / aceitação
- Teste de ponta a ponta (e2e)
Os tipos de teste não funcionais incluem:
- Teste de performance
- Teste de carga
- Teste de estresse
- Teste de segurança
- Teste de conformidade
- Testando usabilidade
Quanto mais complexo o aplicativo obtiver, mais tipos de testes você usará.
Os testes básicos que você deve sempre usar são os seguintes:
- Teste de Unidade
- Teste de integração
- Teste E2E combinado com teste de regressão e teste de segurança
O processo é o seguinte: primeiro você escreve testes para verificar se o aplicativo se comporta conforme o esperado em quase todos os aspectos, incluindo casos de canto. Segundo, se seu aplicativo já estiver ativo, você faz testes para verificar se alguma nova alteração no código quebra a funcionalidade atual.
Nota lateral: além desses testes básicos que você deve usar em qualquer tipo de software, há testes adicionais que você deve escrever para microsserviços. Não se esqueça dos testes de carga, por exemplo, para verificar o comportamento do seu sistema em condições normais e previstas de pico de carga.
Menos conversa, mais código
Nos exemplos a seguir, veremos como podemos implementar esses tipos básicos de teste de software a partir de cima em um microsserviço. O microsserviço usa o protocolo TCP para comunicação e é gravado no Nó JS usando o Estrutura do Nest.
Se o Nest JS parecer novo para você, não se preocupe – tudo o que você precisa saber é o seguinte:
“Ninho é uma estrutura para a construção eficiente e escalável Node.js aplicativos do lado do servidor.
Ele usa JavaScript moderno, é construído com TypeScript (preserva a compatibilidade com JavaScript puro) e combina elementos de OOP (Programação Orientada a Objetos), FP (Programação Funcional) e FRP (Programação Reativa Funcional).
Sob o capô, a Nest faz uso de Expressar, mas também fornece compatibilidade com uma grande variedade de outras bibliotecas, como por exemplo
Fastify, permitindo o uso fácil dos inúmeros plugins de terceiros disponíveis. “—–Descrição oficial do repositório Github
Neste exemplo, usaremos um módulo simples, name: do utilizador, com uma função simples createUser, que criará um novo usuário em nosso banco de dados.
A estrutura de pastas do módulo é semelhante a esta:
Temos um controlador que escuta uma mensagem create_user. Depois de fazer a validação com o ValidationPipe, ele chamará uma função com o mesmo nome em seu serviço.
Dentro do serviço, nós hash a senha do usuário. Em seguida, usando o TypeORM, salvamos um novo usuário em nosso banco de dados.
Para este módulo, usamos TypeORM como o ORM vinculado à tabela User e outro módulo chamado UtilsModule em que temos alguma função auxiliar:
Teste de unidade
UMA unidade é a menor parte testável de um aplicativo, como funções, classes ou procedimentos. Teste de Unidade é um método de teste de software pelo qual unidades individuais de código-fonte são testadas para determinar se elas são boas para nós.
Os testes de unidade são basicamente escritos para garantir que cada implementação simples de diferentes formas de código (funções, classes, etc.) atenda ao seu design e requisitos e se comporte conforme o esperado.
O objetivo de teste de unidade é segregar cada parte do programa e testar se as partes individuais estão funcionando corretamente.
Isso significa que as outras partes do código que não são diretamente da unidade de teste (mas estão vinculadas a ele) serão ridicularizadas.
No nosso caso, a função que queremos testar (createUser) é a nossa unidade que queremos testar. Isso significa que temos que isolá-lo dos outros componentes. Então temos que zombar de nossa repositório do usuário classe que representa o link com o banco de dados usando TipoORM.
Se analisarmos a função (a que está no serviço), veremos que tudo o que faz é hash uma senha e, em seguida, salvar um objeto Usuário dentro de nosso banco de dados. Diante desse fato, escrevemos o seguinte conjunto de testes:
Primeiro, escrevemos um Antes de tudo função que cria nosso módulo de teste. Em seguida, substituímos o repositório original por nossa classe mock, que retornará apenas o objeto que queremos salvar no banco de dados.
Em nossa função, tínhamos um requisito com uma caixa de canto:
- crie um novo objeto de usuário com algumas propriedades (email, senha), mas com uma senha com hash
Nós zombamos da função Salve (), já que é do TypeORM, fora da nossa unidade, e a substituímos por uma função simples que retorna o objeto que passamos.
Então, tudo o que fizemos foi verificar se estávamos enviando o objeto com a propriedade de email correta e com o hash correto.
Teste de integração
Integração Teste é um método de teste de software pelo qual unidades de código-fonte são testadas para verificar a funcionalidade combinada.
Os testes de unidade são basicamente escritos para garantir que o código atenda ao seu design e requisitos e se comporte conforme o esperado. O objetivo do teste de unidade é misturar diferentes módulos e testar se eles interagem corretamente.
Então agora, por nosso exemplo, combinamos nossa UserModule com o módulo TypeORM (dependência) para verificar se o usuário está salvo no banco de dados.
Novamente, temos a mesma função de cima, mas desta vez com o seguinte teste:
Desta vez, em nossa Antes de tudo função que não zombamos do userRepository. Em vez disso, usamos o original, e adicionamos nosso databaseModule o que cria a conexão com nosso banco de dados.
Ao mesmo tempo, como agora usamos um banco de dados real, precisamos escrever várias funções que preparam nosso banco de dados para testes.
Precisamos esvaziar o banco de dados antes e depois dos testes, apenas para ter certeza de que ele está completamente vazio.
Ao mesmo tempo, temos que fechar manualmente a conexão a ele, para não permanecermos com nenhum manipulador aberto depois de concluir os testes.
Com o teste de unidade, verificamos se nossa função estava funcionando como projetada. Então, aqui tudo o que precisamos fazer é testar se nossa função combina com o Salve () do TypeORM e nosso usuário é armazenado dentro do banco de dados.
Escrevemos um nome de função auxiliar getOneUserFromDb, que faz o que diz que faz. Em seguida, verificamos se o email está correto e também a propriedade accountConfimed, que foi definido na classe da entidade com o valor padrão falso.
Teste de ponta a ponta
Teste de ponta a ponta é uma técnica de teste de software usada para testar se o fluxo de um aplicativo está executando conforme projetado do início ao fim.
Fazemos esse tipo de teste para garantir que o aplicativo funcione conforme o esperado em uma situação do mundo real.
Até o momento, testamos se a senha do usuário foi dividida em hash de acordo e se a senha e o email foram salvos no banco de dados.
Agora precisamos testar nossas validações no nível de solicitação. Em nosso controlador, temos um canal de validação que testa a carga útil recebida para verificar se o objeto corresponde a CreateUserDto.
E os testes:
Aqui testamos para ver o que aconteceria se tentássemos criar um usuário, mas não enviassemos o objeto inteiro ou as propriedades em um formato incorreto.
Estes são alguns exemplos dos casos extremos de nossa função que testamos usando apenas três tipos de teste de software.
Testes manuais vs automatizados
Até agora, escrevemos nossos testes manualmente – e, neste caso, isso foi perfeito. Mas quanto mais código você tiver, mais complexos e maiores serão os seus testes.
Por exemplo, se você for testar um sistema de autenticação, terá que replicar todo o comportamento de um usuário real. E você terá que zombar das solicitações e respostas, incluindo cookies e muito mais, apenas para criar o ambiente para seus testes. Um longo conjunto de testes pode levar muito tempo para ser executado.
Felizmente, você tem mais uma opção quando se trata de teste: ferramentas automatizadas. Essas ferramentas possuem funcionalidades integradas para você zombar de todo o ambiente de seus testes, o que facilita o processo de teste.
Você pode ir ainda mais longe e usar ferramentas automatizadas de teste de API para sua aplicação. Essas são ferramentas que vêm com opções extras, o que as torna ótimas para testes de carga, testes de regressão e relatórios de dados para situações reais.
Além disso, eles têm uma boa interface do usuário que facilita a gravação de testes.
Conclusão
Construir software pronto para produção requer testes. E, às vezes, dependendo da complexidade do aplicativo, esses testes podem se tornar um gargalo para você ou sua equipe.
Nesse caso, certifique-se de separar seus conjuntos de testes por tipo, como fizemos anteriormente. E apenas para testar a funcionalidade que pertence ao tipo de teste atual.
Se isso não for suficiente para o seu caso de uso ou se os testes forem muito difíceis de escrever e levarem muito tempo, você poderá usar ferramentas e plataformas automatizadas para facilitar as coisas.
