Invariant-Driven Automated Testing
Esta tese propõe e implementa o PETIT, uma ferramenta que automatiza o teste de microsserviços analisando especificações OpenAPI anotadas com a linguagem APOSTL, permitindo a verificação independente do código fonte.
Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo
Imagine que você é o dono de uma grande rede de restaurantes (o seu negócio) e decidiu contratar chefs independentes para cuidar de cada prato específico: um só faz sobremesas, outro só faz carnes, outro só faz bebidas. Eles trabalham em cozinhas separadas, não se conhecem e você não tem acesso às receitas deles (o código-fonte). Você só sabe o que eles prometem entregar no cardápio (a especificação da API).
O problema? Como você garante que o chef de carnes não vai envenenar o prato ou esquecer de salgar, se você não pode entrar na cozinha dele para vigiar?
Esta tese, de Ana Catarina Malhado Ribeiro, resolve exatamente esse problema para o mundo da tecnologia, onde chamamos esses "chefs independentes" de Microserviços.
Aqui está a explicação simples, usando analogias do dia a dia:
1. O Problema: O Cardápio Mudo
Hoje, as empresas estão migrando para essa arquitetura de "microserviços" (pequenos serviços independentes) muito rápido. O problema é que os "cardápios" (documentos que descrevem o serviço, chamados de OpenAPI) são muito básicos. Eles dizem: "Se você pedir um prato, ele vem numa travessa" (tipo de dado), mas não dizem: "Se o prato estiver estragado, o chef deve devolver o dinheiro" ou "O chef só pode cozinhar se tiver ingredientes frescos".
Sem essas regras claras, testar se o serviço funciona bem é como tentar adivinhar se um carro funciona apenas olhando para ele de fora, sem ligar o motor. As pessoas fazem testes manuais (pedem o prato e veem se vem), o que é lento e propenso a erros.
2. A Solução: O "Contrato Mágico" (APOSTL)
A autora criou uma nova linguagem chamada APOSTL. Pense nela como um contrato mágico que você cola no cardápio do restaurante.
Com esse contrato, você pode escrever regras lógicas simples, como:
- Regra de Entrada (Pré-condição): "Só posso pedir este prato se eu já tiver pago a conta."
- Regra de Saída (Pós-condição): "Depois que eu receber o prato, ele deve estar quente e com o nome do chef escrito no fundo."
- Regra Geral (Invariante): "Nunca pode haver mais de 10 pessoas na fila ao mesmo tempo."
Essa linguagem transforma um cardápio chato em um manual de instruções de teste. Ela diz ao computador exatamente o que deve acontecer antes, durante e depois de cada pedido.
3. O Detetive Robô (PETIT)
Com esse contrato em mãos, a autora criou um robô chamado PETIT.
O PETIT é um detetive que trabalha sozinha. Ela pega o cardápio com o contrato mágico e faz o seguinte:
- Gera Pedidos: Ela cria pedidos de comida (dados de teste) que fazem sentido (não pede "arroz com pneu", pede "arroz com frango").
- Faz os Pedidos: Ela vai até a cozinha (o microserviço) e pede os pratos.
- Verifica o Contrato: Quando o prato chega, ela não olha apenas se veio. Ela lê o contrato mágico e pergunta:
- "O prato está quente como prometido?"
- "O chef devolveu o dinheiro se o prato estava ruim?"
- "A fila ainda tem menos de 10 pessoas?"
Se o chef (o serviço) quebrar uma regra do contrato, o PETIT grita: "ALERTA! O contrato foi violado!" e mostra exatamente onde o erro aconteceu.
4. A Grande Descoberta: A Ordem Importa!
Uma das descobertas mais interessantes do trabalho é que a ordem em que você testa as coisas importa muito.
Imagine que você quer testar se o chef sabe cortar carne (Mutador) e se ele sabe servir o prato (Observador).
- Se você pedir para servir o prato antes de ele ter cortado a carne, o teste vai falhar (e não será culpa do chef, mas da sua ordem de teste).
- O PETIT permite que você escolha a estratégia de teste:
- CMO: Primeiro cria os dados (Construtor), depois muda (Mutador), depois verifica (Observador).
- MOC: Primeiro tenta mudar coisas que não existem (para ver se o sistema avisa que está errado), depois cria, depois verifica.
O estudo mostrou que, dependendo da ordem, o robô consegue encontrar erros que estariam escondidos se você testasse de qualquer jeito.
Resumo da Ópera
Esta tese nos dá duas ferramentas poderosas:
- Uma linguagem (APOSTL) para escrever regras claras nos cardápios dos serviços digitais.
- Um robô (PETIT) que lê essas regras e testa automaticamente se os serviços digitais estão cumprindo o que prometem, sem precisar entrar no código deles (caixa preta).
É como ter um inspetor de qualidade que lê o contrato, pede o prato, verifica se está gostoso e avisa se o restaurante está trapaceando, tudo isso de forma automática e super rápida. Isso é essencial para garantir que as tecnologias modernas, que dependem de muitos serviços conversando entre si, não caiam em desastre.
Afogado em artigos na sua área?
Receba digests diários dos artigos mais recentes que correspondam às suas palavras-chave de pesquisa — com resumos técnicos, no seu idioma.