Interface, servidor e banco juntos

Uma validação feita apenas na tela melhora a experiência do usuário, mas não garante que a regra esteja protegida em todas as entradas do sistema.

O caminho de um pedido

Quando uma dessas partes envia, interpreta ou grava algo de forma incorreta, podemos ter um problema de integração.

API: um ponto de comunicação entre partes

Na Cantina Horizonte, a interface usa endereços como:

GET /api/produtos
POST /api/pedidos

GET e POST são métodos do protocolo HTTP. HTTP significa Hypertext Transfer Protocol, em português Protocolo de Transferência de Hipertexto. Aqui basta entender que esses métodos indicam tipos diferentes de operação.

Neste módulo, não vamos transformar essa etapa num curso de desenvolvimento de API. O servidor já está pronto. Nosso foco é testar a comunicação.

Uma ferramenta entra porque agora precisamos dela

Até aqui, a tela bastava para várias atividades. Agora queremos enviar requisições diretamente ao servidor, escolhendo exatamente os dados.

Assim podemos testar o servidor mesmo quando a tela bloqueia determinada entrada.

Prepare o laboratório

Vamos manter o servidor aberto enquanto enviamos as requisições.

Primeiro, uma requisição simples

No Bruno, crie uma requisição e envie:

GET http://127.0.0.1:8000/api/produtos

O servidor deve responder com a lista de produtos.

O número 200 indica que a requisição foi atendida com sucesso. Ele é um código de status HTTP: um número que resume o resultado da requisição.

Agora crie um pedido sem usar a tela

Envie uma requisição POST para:

http://127.0.0.1:8000/api/pedidos

No corpo da requisição, envie:

{
  "itens": [
    {
      "produto_id": 3,
      "quantidade": 2
    }
  ]
}

Esse texto está no formato JSON, sigla de JavaScript Object Notation. É um formato textual muito usado para transportar dados entre sistemas.

Se o pedido for criado corretamente, a aplicação responde com código 201.

O código de status também faz parte do comportamento

Não é necessário decorar todos os códigos HTTP existentes. Aqui estamos aprendendo a comparar o que a API deveria responder com o que realmente respondeu.

Teste uma regra que a tela poderia esconder

Envie quantidade 0 diretamente ao servidor:

{
  "itens": [
    {
      "produto_id": 3,
      "quantidade": 0
    }
  ]
}

Pela RF-03, o resultado esperado é rejeitar a operação.

Se você já corrigiu a função validar_quantidade durante as práticas anteriores, deve receber código 400. Se estiver com a versão original v1, o servidor pode aceitar o pedido. Nesse caso, você acabou de revelar o mesmo defeito sem passar pela interface.

Integração também significa verificar o efeito no banco

Uma resposta 201 não prova sozinha que tudo aconteceu corretamente.

Suponha que o Salgado tenha estoque 10 e você crie um pedido com quantidade 3. Depois da criação, esperamos encontrar estoque 7.

Um defeito que aparece só quando olhamos a sequência

Antes deste cenário, volte aos dados iniciais. Encerre o servidor com Ctrl+C, execute resetar_dados_windows.bat e inicie a Cantina novamente. O Sanduíche deve voltar ao estoque 8.

Agora envie um pedido com quantidade 10.

{
  "itens": [
    {
      "produto_id": 4,
      "quantidade": 10
    }
  ]
}

A quantidade 10 está dentro do limite máximo por item, mas ultrapassa o estoque disponível.

Pela RF-04, o pedido deveria ser rejeitado. Depois da tentativa, consulte os produtos novamente e observe o estoque.

Contrato: combinar a forma da conversa

A interface pode enviar:

{ "quantidade": 2 }

mas o servidor pode esperar:

{ "qtd": 2 }

Mesmo que os dois lados estejam “funcionando”, eles não conseguem conversar porque não concordam sobre a estrutura.

Teste de integração não precisa começar pelo sistema inteiro

Podemos testar apenas a conversa entre servidor e banco, ou entre uma regra e outra parte do sistema. Quanto menor o recorte necessário para responder à pergunta, mais fácil costuma ser localizar a origem do problema.

Isso retoma o que aprendemos na Etapa 7: níveis diferentes respondem perguntas diferentes.

Depois do manual, automatize uma verificação

Também podemos usar o pytest para chamar a API automaticamente. Um teste pode ter esta ideia:

def test_api_deve_rejeitar_quantidade_zero(client):
    resposta = client.post(
        "/api/pedidos",
        json={"itens": [{"produto_id": 3, "quantidade": 0}]}
    )

    assert resposta.status_code == 400

O objeto client representa um cliente de teste preparado para conversar com a aplicação. Vamos manter a configuração pronta quando transformarmos essa ideia em uma suíte de integração; o foco agora é perceber que o mesmo caso manual pode ser automatizado.

Um cuidado importante: banco de teste

Testes de integração podem criar pedidos, alterar estoque e mudar status. Por isso, não devemos executar experiências desse tipo em dados reais.

Use o roteiro prático

Preparei uma sequência curta para executar no Bruno, começando por uma consulta simples e chegando aos cenários de quantidade e estoque.

Prática · não olhe apenas para a resposta

Mas ainda existe uma parte que não testamos

Agora sabemos testar função, servidor, API, banco e integração.

Mesmo assim, o usuário não trabalha enviando JSON no Bruno. Ele clica, digita, muda quantidades e finaliza pela interface.