APRENDER. PRATICAR. EVOLUIR.Especificar o comportamento
O exercício usa uma regra inventada: calcular dois por cento de um montante decimal finito e não negativo, devolvendo cêntimos com desempate HALF_UP. Essa regra serve para criar um defeito observável e não descreve um produto bancário real. Antes de programar o teste, regista exemplos aprovados do contrato, incluindo entradas e saídas esperadas. Para 100.00, o resultado é 2.00. Para 101.25, o produto exato é 2.025 e o resultado acordado é 2.03. Decimal é construído a partir de texto neste guião. A escolha evita introduzir uma conversão binária desnecessária no exemplo, mas continua a exigir precisão, limites e regras adequadas quando se desenha uma aplicação real.
O caso que distingue implementações
B usa HALF_EVEN onde o contrato fictício exige HALF_UP. No valor habitual 100.00, as duas regras produzem 2.00; o smoke test passa na candidata realmente carregada. O valor 101.25 força o empate e distingue as implementações: B devolve 2.02, enquanto A e C devolvem 2.03. O problema não é apenas formatação, pois o valor muda um cêntimo. Um teste útil seleciona entradas que distinguem comportamentos permitidos de desvios plausíveis. Não precisas de multiplicar casos idênticos para encontrar este defeito; precisas de compreender o requisito e a fronteira. Outros produtos e operações podem exigir regras diferentes, que devem ser confirmadas com os responsáveis pelo contrato.
Cobertura e resultado
Compara candidate-B-smoke e candidate-B-full. No primeiro, a origem corresponde e um teste passa, mas o gate assinala resultados obrigatórios em falta. No segundo, quatro testes são executados e a asserção de fronteira falha. São problemas diferentes: falta de cobertura e desvio funcional observado. Os outros dois casos exigem ValueError para -1 e NaN, segundo a regra fictícia. Esses testes negativos passam quando a rejeição esperada ocorre; não escondem qualquer erro arbitrário. O conjunto continua pequeno e não cobre todas as entradas, volumes ou integrações. Ao apresentar resultados, inclui quais casos foram executados, quais passaram e o que permanece fora do âmbito. Uma contagem agregada não substitui essa leitura.
Corrigir sem adaptar o teste ao defeito
Num cenário fictício, a janela aproxima-se e o fornecedor propõe aceitar 2.02 para manter tudo verde. Se o contrato continua a exigir HALF_UP, alterar o esperado elimina o controlo que encontrou o problema. Corrige a implementação para C e executa de novo os casos relevantes, confirmando a origem carregada. O guião observa quatro aprovações em C, incluindo a fronteira e as duas rejeições. Conserva o histórico de B: explica a causa e permite rever a correção. Se o negócio quiser mudar legitimamente a regra, trata essa alteração como mudança de requisito, com impacto e exemplos revistos. O resultado da função sob teste não deve ser a única fonte do seu próprio valor esperado.
Aceitação proporcional à evidência
O gate local combina origem e bytes correspondentes com os quatro IDs aprovados. Isso permite concluir que a candidata C observada cumpriu aqueles casos no runtime registado. Não prova que um serviço real está pronto para qualquer carga ou dependência. O laboratório não instala wheels, não executa uma pipeline externa e não testa um serviço empresarial. Para a aceitação representativa, planeia com os responsáveis os ambientes, configurações, dependências, integrações e observações operacionais necessárias. Mantém os controlos sobre quem produz e entrega a evidência. Um hash lido num ficheiro próprio é útil para este diagnóstico, mas não substitui proteção da execução, origem autenticada ou validação da cadeia de fornecimento.
Oficina de aceitação e resumo
Propõe uma oficina com negócio, QA e RUN. O negócio fornece a regra fictícia; QA escolhe um caso habitual, uma fronteira e duas entradas recusadas; desenvolvimento explica a alteração de B para C. RUN recebe os relatórios e escreve uma recomendação que identifica o alvo, o âmbito aprovado e as verificações de destino ainda necessárias. O facilitador introduz depois a proposta de usar a própria função para calcular o esperado. A equipa deve explicar por que essa comparação pode repetir o defeito em ambos os lados. A oficina humana não foi executada. O laboratório automatizado passou dez grupos duas vezes. Resume a sequência: contrato, exemplos discriminantes, alvo confirmado, resultados, correção e aceitação com limites explícitos.
python3 content/labs/cicd-target/run.py --output /tmp/dr-cicd-target-second.json
# Fictional rule: fee=2%, finite nonnegative decimal input, HALF_UP to cents.
# candidate-B-smoke: 100.00 -> 2.00, one passing test, required results missing.
# candidate-B-full: 101.25 -> 2.02, test_boundary fails (expected 2.03).
# corrected-C-full: four required tests pass, origin matches, gate accepts.
# Negative inputs -1 and NaN must raise ValueError under this fictional contract.
# No actual payment, external service, business policy or production approval.A candidata B passa 100.00 → 2.00, mas devolve 2.02 para 101.25 quando o requisito fictício exige 2.03. C corrige o modo de arredondamento.
Armadilhas comuns
Usar só entradas habituais, mudar o esperado para acompanhar um defeito, adotar uma regra financeira universal inexistente ou declarar prontidão global com quatro testes locais.
Tópicos relacionados: Identidade de artefactos · Evidência de testes · Gestão de releases
Identificar o alvo é necessário, mas a aceitação também depende de casos relevantes e expectativas independentes do código que está a ser avaliado.
Referência: decimal: Decimal arithmetic · CI/CD practices 2026-09; scoped GitHub Actions GitLab Jenkins and Azure DevOps Services documentation