Arquitetura de microsserviços: ferramentas para um processo (mínimo) de qualidade Link para o cabeçalho
Todo mundo fala de transformação digital, de como APIs podem conectar seu negócio na sociedade da informação e o céu é o limite inserindo tudo isso em uma arquitetura de microsserviços.
Porém, em proporção menor vemos sugestões para garantir a qualidade nas várias camadas que existem em uma arquitetura de microsserviços. Neste artigo, citarei rapidamente ferramentas que usamos no projeto em que trabalho para melhorar nossos processos de qualidade.
Contextualizando os testes Link para o cabeçalho
O alicerce para nossa estratégia foram os artigos no site do Martin Fowler, especialmente os voltados para uma arquitetura de microsserviços, que trazem uma nova adequação da tão conhecida Pirâmide de Testes.
Nessa Pirâmide:
- Testes unitários testam a menor parte do software (que é testável) determinando se o comportamento é o esperado, como podemos ler aqui.
- Testes de integração verificam interações entre os componentes internos e externos para detectar algum defeito da interface, podendo envolver um único componente ou vários. Temos também testes de contrato de integração, que verifica se esse contrato atende ao que o consumidor espera. Leia mais nesse post.
- Testes de componente isolam componentes substituindo as interfaces reais por interfaces internas para o teste, como explicado neste tópico.
- Testes end-to-end (ou Broad Stack Tests) verificam se o sistema atende aos requisitos e se alcança seus objetivos, através de testes realizados de ponta-a-ponta em todo o sistema.
- Testes exploratórios são os testes executados por algum QA, explorando manualmente o sistema, buscando falhas não mapeadas nos testes de outras camadas e educando melhor os testes já automatizados.
E como é a nossa arquitetura? Link para o cabeçalho
Nossa arquitetura é uma arquitetura de microsserviços, mas utilizando a query language GraphQL para ser quem expõe e redireciona a maior parte dos dados.
Se vocês quiserem saber um pouco mais sobre como o GraphQL pode ser utilizado em um projeto, recomendo fortemente a leitura de um artigo muito bom do pessoal do Netflix citando os aprendizados que a adoção dele levaram, e o pessoal do GetNinjas também arrasaram em um post detalhando como ele se envolve com essa arquitetura.
Ferramentas e processos para cada camada Link para o cabeçalho
Testes unitários Link para o cabeçalho
Como lidamos com microsserviços em Java, em uma arquitetura MVC, utilizamos a gama de possibilidades que o Spring nos oferece, junto com as ferramentas que possui para testes unitários e de integração.
Testes de integração e de componente Link para o cabeçalho
Para esses testes, estamos usando o poderoso Postman, criado com o objetivo de testar serviços RESTful, e que consegue validar:
- Cada integração através das interfaces testáveis em APIs REST e também através das chamadas de queries e mutations no motor GraphQL.
- O funcionamento completo de cada componente, ao se esperar que o retorno da requisição esteja dentro do esperado.
Hoje, o Postman não possui nativamente o fetch do schema GraphQL como seu concorrente mais simples e moderninho, o Insomnia. Porém, mudanças estão surgindo e ele está começando a tirar o sono dos concorrentes.
Testes end-to-end Link para o cabeçalho
Para estes testes, usamos o famoso Cucumber, com sua implementação em Javascript. Todo use case escrito com o BDD é passado para ele.
Porém, com os use cases crescendo e o esforço de se manter o Cucumber, estamos estudando (e sepá usaremos!) o simples e poderoso Karate Framework, que combina “API test-automation, mocks and performance-testing into a single, unified framework”, criando uma espécie de DSL voltada para HTTP, JSON e XML - o que é interessante para nosso cenário, especialmente com um time bem técnico. O pessoal do Hackernoon explica melhor isso.
Porém, além de APIs REST e GraphQL, o time no qual trabalho também é responsável por um portal web - e, para automação com telas, nada mais clássico do que o maduro Selenium. Estamos também começando a utilizar o Zalenium, escalável e que permite o paralelismo dos testes.
Testes exploratórios Link para o cabeçalho
Quem geralmente procura erros, explora o componente de software e cria testes criativos ao navegar por cenários não óbvios? O QA! Obviamente, ele fará isso apenas se os demais tipos de teste estiverem sendo contemplados em outras ferramentas, por questões de tempo e de paciência também - afinal, nada mais desgastante para o QA do que exigir que execute apenas testes que poderiam ser elaborados e automatizados em outras camadas.
E o nosso BDD? Link para o cabeçalho
Para o BDD, adaptamos a Three-meeting-friendly para um processo de revisão de documentação, que envolve:
- O Product Owner, escrevendo a documentação funcional, onde serão explicados e mapeados os requisitos de determinada API/recurso.
- O Arquiteto, escrevendo a documentação técnica com os diagramas de sequência e um bom Swagger.
- O QA, que irá analisar estes documentos e escrever os BDDs.
Encontramos novos desafios no processo Link para o cabeçalho
- Estamos construindo hoje um ambiente de QA, para que os testes sejam executados isoladamente dos demais ambientes (sem sobrecarregar o ambiente de
dev). - Precisamos ainda melhorar a forma de levar os relatórios e métricas dos testes para o dia a dia dos desenvolvedores; ideias desde ter uma TV que exibe as builds que quebraram (nos testes) até ter um “gerente de testes” surgiram, mas estamos ainda alinhando qual o melhor caminho.
- Testes de Performance ainda não entraram no nosso processo de
CI/CDe de desenvolvimento - mais uma novidade que está no nosso roadmap!
Bem, gostaria de ter passado para vocês um pouquinho do que foi preciso para lidar com os processos de qualidade para arquiteturas de microsserviços.
Agradecimentos ao Guilherme Machado Rogatto, que me lembrou de citar o Zelenium :)
Espero ter ajudado!
Abraços!
Postagem migrada do Medium. Link para o cabeçalho
- Por Mai R. on May 24, 2019.
- Link Original