Módulo 4: Parametrizar e rodar no CI

Quando a mesma verificação vale pra várias colunas/valores, não copie a função. Parametrize:

@pytest.mark.parametrize(
    "coluna, tabela, permitidos",
    [
        ("status", "pedidos", {"novo", "pago", "enviado", "entregue", "cancelado"}),
        ("severidade", "defeitos", {"baixa", "media", "alta", "critica"}),
        ("resultado", "execucoes_teste", {"passou", "falhou", "bloqueado", "pulado"}),
    ],
)
def test_coluna_so_tem_valores_do_dominio(db, coluna, tabela, permitidos):
    achados = {r[0] for r in db.execute(f"SELECT DISTINCT {coluna} FROM {tabela}")}
    assert not (achados - permitidos)

No relatório viram 3 casos separados: …[status-pedidos-permitidos0] PASSED, etc. Se um domínio quebrar, você vê exatamente qual, sem ambiguidade.

O repositório já tem o workflow .github/workflows/trilha-3-pytest.yml. Ele instala o Python, instala o pytest e roda a suíte numa máquina do GitHub a cada push que mexa em trilha-3/ ou no banco, e também pelo botão Run workflow na aba Actions.

jobs:
  pytest:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with: { python-version: "3.12" }
      - working-directory: trilha-3
        run: pip install -r requirements.txt
      - working-directory: trilha-3
        run: pytest

• Se pytest sai com código ≠ 0, o passo falha e o check do commit fica vermelho: visível no PR, dá pra bloquear o merge.
• Os 3 xfail mantêm a suíte verde no CI. No dia que um deles virar XPASS (dado corrigido), o strict=True derruba o build de propósito: sinal de "remova o marcador".
• Veja cada rodada, com o log completo, na aba Actions do repositório.

1. Escreva um teste parametrizado novo: pra cada tabela (clientes, produtos, pedidos), confira que id não se repete (SELECT id, COUNT(*) … GROUP BY id HAVING COUNT(*) > 1 tem que vir vazio).
2. Rode local, veja os 3 casos verdes.
3. Faça commit e push. Abra a aba Actions no GitHub e veja o workflow rodar sozinho.

A partir daqui, toda query de investigação que você escrever pode virar uma linha de defesa que roda pra sempre.

Olhar de QA

Um teste automatizado só protege enquanto alguém olha o resultado: por isso ele precisa estar no CI, e por isso o build precisa reprovar. E resista sempre à tentação mais perigosa desta profissão: afrouxar a asserção para a suíte ficar verde. No instante em que isso vira hábito, a suíte deixa de ser proteção e passa a ser enfeite, com o custo de manutenção de uma proteção.