O problema de uma automação sem organização

Em projetos de automação API é comum começar chamando endpoints diretamente dentro dos testes. Embora funcione inicialmente, essa abordagem aumenta o custo de manutenção conforme o projeto cresce. 

test()
  |
  |-- request.post()
  |-- request.get()
  |-- validações
  |-- autenticação

Com muitos cenários, qualquer alteração de endpoint ou autenticação exige mudanças em vários arquivos.

Separando responsabilidades

Uma arquitetura mais sustentável divide o código em camadas: 

Teste
  |
Service
  |
ApiClient
  |
API

Teste

Responsável por validar comportamento e regras do cenário.

Service

Centraliza operações relacionadas a um recurso da API. 

cartService.addProduct(
  cartId,
  productId,
  quantity
);

ApiClient

Controla detalhes técnicos como URL base, headers, autenticação e tratamento de respostas HTTP.

Exemplo aplicado

Em vez de realizar uma chamada HTTP diretamente no teste: 

request.post('/carts/id')
usamos uma abstração de serviço: 
await cartService.addProduct(
  cart.id,
  product.id,
  1
);

O teste fica focado no comportamento esperado, não nos detalhes de comunicação.

Benefícios dessa arquitetura

  • Menor duplicação de código.
  • Manutenção centralizada.
  • Testes mais legíveis.
  • Facilidade para evolução do framework.
  • Separação clara entre negócio e infraestrutura.

Conclusão

Uma boa arquitetura de automação não elimina complexidade, mas organiza onde ela deve existir. Separar testes, serviços e cliente HTTP permite que o projeto cresça mantendo previsibilidade e facilidade de manutenção.