Projeto final

Entregável: um arquivo projeto-final/01-perguntas.md com no mínimo 8 perguntas que você levaria à reunião de refinamento, cada uma com uma frase dizendo por que ela importa (qual o risco se ninguém responder).

Como produzir as perguntas, em vez de esperar que apareçam:

• passe as técnicas do Módulo 3 de Fundamentos pela regra: toda vez que você não souber preencher a coluna "resultado esperado", achou uma pergunta;
• passe o pente dos tipos do Módulo 2: segurança, performance, usabilidade, acessibilidade;
• pergunte pelos limites que ninguém escreve: zero, vazio, exatamente no valor, um item só.

Dica de professor: as três perguntas mais valiosas desta história têm a ver com o que é "nunca fez um pedido", o que acontece com pedido cancelado e sobre qual valor incide o desconto. Se você chegou nelas sozinho, está pensando como QA.

Entregável: projeto-final/02-casos-de-teste.md com uma tabela de casos, indicando para cada um qual técnica o gerou.

Use as quatro, em ordem:

Técnica	O que ela deve fazer aparecer aqui
Partição de equivalência	cliente novo × cliente com histórico; cupom válido, inexistente, expirado, já usado; campo vazio
Valor limite	itens somando R$ 99,99 / R$ 100,00 / R$ 100,01; pedido com 1 item; carrinho vazio
Tabela de decisão	é cliente novo? × atinge o mínimo? × já tem outra promoção? Todas as combinações, e a mensagem esperada em cada uma
Transição de estado	aplicar o cupom e depois remover itens até cair abaixo de R$ 100; aplicar, cancelar o pedido, tentar usar o cupom de novo; usar o cupom em dois pedidos simultâneos

Marque com ⚠ os casos cujo resultado esperado depende de uma pergunta da Etapa 1 que ainda não foi respondida. Essa marcação é o que transforma a sua tabela num instrumento de negociação com o time.

Antes de testar a funcionalidade nova, entenda o terreno. Entregável: projeto-final/03-consultas.sql, com as queries comentadas e o que cada resultado significa.

Responda, no banco de prática (Trilha de SQL):

1. Quantos clientes nunca fizeram um pedido? (São os elegíveis ao cupom.)
   Dica: é o padrão LEFT JOIN ... WHERE ... IS NULL. Cuidado com a pegadinha do Módulo 4.
2. E se pedidos cancelados não contarem como "já fez um pedido"? Quantos clientes passam a ser elegíveis?
   A diferença entre as duas respostas é exatamente o custo de não ter perguntado na Etapa 1.
3. Quantos pedidos teriam atingido o mínimo de R$ 100,00 em itens?
4. Existem pedidos cujo valor_total já não bate com a soma dos itens? Quantos, e quais?
   Se já há divergência hoje, qualquer teste do novo cálculo vai dar falso positivo. Isso precisa ser dito ao time antes da entrega.
5. Monte a massa de teste: um INSERT que cria um cliente novo, sem nenhum pedido, para você usar nos testes manuais.

Faça a Etapa 3 dentro de uma transação e confira antes de confirmar: Módulo 7.

Entregável: projeto-final/04-testes-api.md: os cenários de API que você executaria, com a verificação de cada um. Use a API falsa da Trilha 4 para praticar a mecânica.

Cubra as três camadas, sem parar na primeira:

• Status: 200/201 no sucesso; 400 no cupom inválido, no cliente não elegível, no valor abaixo do mínimo; 405 nos métodos errados.
• Contrato: a resposta traz os campos de desconto? Com que tipo? O valor_total vem como número? Existe campo a mais que não deveria estar exposto?
• Valor e efeito colateral: o desconto devolvido é realmente 10% dos itens? Depois do POST, um GET encontra o pedido? E, o mais importante, o que ficou gravado no banco bate com o que a API devolveu?

Inclua ao menos dois cenários de abuso: aplicar o cupom duas vezes no mesmo pedido, e enviar o preço do item pelo corpo da requisição para ver se a API confia no que o cliente mandou.

Entregável: trilha-3/test_05_projeto_final.py: um arquivo de testes de verdade, rodando na sua máquina.

Escreva, no mínimo:

1. um teste que confirme que nenhum pedido tem valor_total divergente da soma dos itens, com tolerância de arredondamento;
2. um teste parametrizado que confira o domínio de valores de três colunas (status de pedido, severidade e resultado de execução);
3. um teste que confirme que não existe pedido apontando para cliente inexistente;
4. um teste com @pytest.mark.xfail(strict=True) para uma regra que você sabe que o dado atual viola, com a razão documentada.

Requisitos de qualidade: toda mensagem de assert deve listar quais linhas falharam. Lembre que, no CI, essa mensagem é o relatório de bug.

Entregável: o seu branch com os testes rodando no GitHub Actions.

1. Commit e push do branch projeto-final.
2. Abra um Pull Request com descrição em três seções: o que muda, por quê, como testar.
3. Veja o workflow rodar na aba Actions. Abra o log e encontre a linha em que os seus testes executaram.
4. Quebre de propósito: mude uma asserção para algo falso, dê push e confirme que o check fica ✗ no PR. Depois conserte e veja voltar ao ✓.
5. Acrescente o badge do workflow no seu README.md.

O passo 4 é o mais importante: até você ver o vermelho aparecer por causa de uma mudança sua, o pipeline é abstração.

Entregável: projeto-final/07-relatorio.md, com duas partes.

a) Um relatório de defeito completo: use um achado real das Etapas 3 ou 4 (os pedidos com valor_total divergente servem). Estrutura do Módulo 5 de Fundamentos: título na fórmula, ambiente, pré-condições, passos, esperado com a razão, obtido, evidência, e severidade e prioridade justificadas separadamente.

b) Um resumo de sessão, nos quatro itens:

• O que cobri: cenários, camadas, o que foi automatizado;
• O que achei: defeitos, ambiguidades, inconsistências de dados;
• O que não deu tempo: dito explicitamente, sem constrangimento;
• O que me preocupa: os riscos que você não conseguiu descartar.

Esse resumo é o que uma pessoa que decide precisa ler antes de liberar a entrega. Escrever bem os quatro itens é a habilidade mais transferível deste curso inteiro.