Módulo 3: Regras de negócio e POST

• POST cria coisa. Segundo argumento vira o corpo: await api('POST', '/defeitos', { titulo: 'x', severidade: 'alta' }).
• Sucesso: geralmente 201 Created, e o corpo traz o recurso criado (com id novo, campos default preenchidos).
• Entrada inválida: 400 Bad Request, a API não deve criar nada e deve explicar o que faltou.
• Efeito colateral: depois de um POST bem-sucedido, um GET seguinte tem que enxergar o que foi criado. Teste isso: é onde mora bug de "cadastrou mas não salvou".

Dica: o botão Resetar dados desfaz os POSTs que você fez, pra rodar de novo do zero.

const r = await api('POST', '/defeitos', { titulo: 'teste manual', severidade: 'baixa' }); check('status 201', r.status === 201); check('ganhou id', typeof r.json.id === 'number'); check('status inicial aberto', r.json.status === 'aberto');

Olhar de QA

Depois de todo POST bem-sucedido, pergunte-se duas coisas que o status sozinho não responde: gravou mesmo? (faça o GET seguinte) e gravou só o que deveria? (no caso do 400, conte os registros antes e depois). Criação silenciosa depois de um erro é um defeito sério: a pessoa tenta de novo e ficam dois registros. E teste sempre o envio repetido: clique duplo e nova tentativa automática são realidade em produção, não hipótese.