REST Assured e TestSprite: asserções fluentes, cobertura manual

O veredito primeiro

• Escolha o REST Assured se você é um time JVM que quer testes de API na mesma linguagem, no mesmo build e no mesmo processo de revisão do próprio serviço.

• Escolha o TestSprite se a amplitude da cobertura e os quatro problemas de estado são o gargalo, e não a sintaxe das asserções.

• Use os dois se você tem uma suíte REST Assured que as pessoas realmente mantêm. Preserve os testes que você especificou de propósito e acrescente amplitude gerada em volta deles.

Lado a lado

Onde o REST Assured é a escolha certa

• Testes como parte da base de código. Mesma linguagem, mesma revisão, mesmo build. Para alguns times isso é inegociável, e é uma posição justa.

• Asserções customizadas complexas. Quando a corretude exige lógica de verdade em vez de comparação de campos, uma linguagem completa é a ferramenta certa.

• Investimento já feito na JVM. Fixtures compartilhadas, objetos de domínio e ferramentas de build que você já tem.

O que continua sendo tarefa sua

Sessões expiram, identificadores precisam viajar entre chamadas, alguns endpoints não podem ser chamados antes de outros e cada execução deixa registros para trás. O REST Assured não tem opinião sobre nenhum desses pontos, o que é correto para uma DSL e significa que os quatro caem na sua infraestrutura de testes.

Há também um problema com o formato da cobertura: uma suíte escrita à mão cobre aquilo de que alguém se lembrou, e os caminhos de erro e valores de fronteira que quebram em produção são justamente os que ninguém escreve no fim de uma sprint. Os quatro mecanismos estão descritos na documentação de testes de API.

O problema do grafo de fixtures, na prática

O ponto em que uma suíte REST Assured começa a custar mais do que devolve costuma aparecer nas fixtures do JUnit, não nos testes.

Um teste precisa de um pedido. Um pedido precisa de um cliente e de um produto. O cliente precisa de uma conta em um determinado plano. Expresso como fixtures, isso é uma árvore pequena, e o JUnit a monta sem reclamar. Aí um segundo teste precisa do mesmo cliente, mas de outro produto, e um terceiro precisa de dois clientes. Agora a árvore virou um grafo, as fixtures passam a receber parâmetros e o código de setup fica maior que as asserções.

Nada disso é um problema de linguagem e nada disso se resolve com uma DSL mais ergonômica. É o custo de expressar um grafo de dependências em um framework cujo modelo é uma árvore, e é exatamente isso que uma camada feita para esse fim elimina.

Usando os dois

Mantenha o REST Assured para os casos que você especificou de propósito e para asserções que exigem lógica de verdade. Deixe a cobertura gerada dar conta da amplitude em toda a superfície. Os dois rodam a partir do mesmo pipeline.

Se você está avaliando, quebre alguma coisa de propósito

Introduza uma regressão real, como um botão de salvar que não persiste mais, e observe o que cada ferramenta reporta. Três perguntas: ela falha? a falha nomeia a divergência de fato? e a pessoa ou o agente que for corrigir consegue partir daquela saída sem reconstruir a história do zero? Uma ferramenta que reporta sucesso em uma execução que nunca chegou às suas asserções foi reprovada no único teste que importa.

Se o pipeline pertence a outro time, o GitHub App é o caminho de menor resistência: é um webhook, não muda nada no seu repositório e dispara quando o seu build avisa que a nova versão está no ar. Se você prefere que a verificação fique visível no próprio repositório, um passo do GitHub Actions faz isso. Veja o repositório da CLI.

O que o TestSprite resolve no nível da suíte

Os quatro problemas que ficam fora do alcance de qualquer DSL. Auto-Authentication para o tempo de vida da sessão, Dynamic Variables para os valores capturados entre chamadas, Dependency Chains para que a ordenação seja derivada em vez de codificada no aninhamento de fixtures, e Auto-Cleanup vinculado ao que cada execução criou.

A cobertura é gerada a partir da sua especificação e de uma passagem de descoberta sobre o serviço em execução, e depois refinada em linguagem simples, o que significa que os valores de fronteira e os caminhos de erro existem sem ninguém precisar escrevê-los às onze da noite.

O que isso deixa para o seu time JVM: o REST Assured para os casos que você especificou de propósito e para asserções que exigem lógica de verdade, sem nenhum grafo de fixtures para manter por baixo. Os dois rodam a partir do mesmo pipeline.