APRENDER. PRATICAR. EVOLUIR.O que significa passar
Começa por escrever o resultado funcional que a entrega precisa de demonstrar. No exercício, dois IDs são obrigatórios: um confirma uma soma e outro confirma a rejeição de uma entrada inválida. Esta é uma política pedagógica explícita, não uma regra universal de CI/CD. O runner fornece observações; a equipa decide quais satisfazem cada requisito. Um resultado global favorável pode coexistir com testes ignorados ou falhas classificadas como esperadas. Numa aplicação real, acrescenta o contexto da plataforma, entradas, configuração e versão exercitada. Não inventes uma percentagem de aprovação para substituir a discussão dos comportamentos críticos. Uma exceção altera a decisão de risco, mas não transforma a observação original num teste aprovado.
Descoberta e execução
Executa o laboratório numa cópia local e compara required-tests-pass com wrong-pattern-empty-suite. A primeira execução encontra dois métodos no ficheiro test_case.py; a segunda usa checks_*.py e não encontra nenhum. As duas terminam com zero no runtime registado, mas só a primeira satisfaz o conjunto obrigatório. Antes de corrigir código da aplicação, revê o diretório inicial, o padrão e os IDs selecionados. A descoberta de unittest importa módulos: a fixture import lança deliberadamente ImportError e produz um resultado de erro. Por isso, descobrir testes de uma contribuição desconhecida já exige respeitar a fronteira de confiança do executor. O ensaio usa exclusivamente código original controlado, sem contribuições externas ou credenciais.
Interpretar cada resultado
Compara as fixtures skip, expected, unexpected, fail e error. O teste ignorado não executa o seu corpo; o teste com falha esperada conserva uma divergência conhecida; ambos deixam passedIds vazio. Quando a asserção marcada expectedFailure passa, o runtime regista unexpectedSuccesses e devolve falha: é necessário rever a anotação e a alteração funcional. A fixture fail executa uma comparação que falha. A fixture error falha em setUp antes de executar essa comparação. Não declares a funcionalidade correta ou incorreta apenas a partir de um problema de preparação. Dá nomes claros aos estados no relatório operacional e indica quem resolve cada condição antes de repetir a verificação.
Contagens e cobertura
A fixture subtests avalia três valores num só método e regista testsRun igual a um. O exemplo mostra por que uma contagem precisa de unidade e contexto. Um refactor pode dividir um método em vários sem aumentar os comportamentos avaliados; também pode reduzir métodos sem perder as mesmas entradas. No trabalho, mantém um mapa entre requisitos importantes e verificações representativas. Se o único teste de arredondamento desaparecer e forem acrescentados dois testes de formatação, o total cresce enquanto a cobertura financeira piora. Revê alterações ao conjunto obrigatório como parte da alteração de software. Usa o número de testes como sinal para investigar, acompanhado de resultados e âmbito, em vez de o tratar como qualidade demonstrada.
Decidir durante uma janela
Numa situação fictícia de APS, o fornecedor move os testes quinze minutos antes da janela de batch. O runner termina rapidamente e o gestor recebe uma mensagem verde. Pede o relatório detalhado: zero testes significa que o critério de reconciliação não foi observado. Coordena a correção da seleção e a nova execução; RUN conserva o diagnóstico e informa o responsável pela janela. Se não houver tempo, propõe uma nova janela ou uma exceção formal ao responsável autorizado, com impacto, medidas, prazo e condição de revisão. Não substituas a lacuna por um teste administrativo que apenas procura um ficheiro. Estes papéis e decisões são exemplos de aprendizagem e não descrevem procedimentos de qualquer banco.
Oficina e resumo
Para uma oficina de vinte minutos, divide responsabilidades entre desenvolvimento, QA e RUN. Desenvolvimento explica o seletor; QA define quais IDs e comportamentos são obrigatórios; RUN interpreta os resultados e formula uma recomendação de avanço. Usa três cartões: suite vazia, teste crítico ignorado e falha de preparação. Cada participante deve distinguir a observação, a hipótese e a evidência que falta, sem editar o relatório para obter aprovação. Compara as respostas com o guião e regista divergências de interpretação. Esta oficina está proposta, mas não foi realizada por um grupo humano. Retém a sequência: definir requisitos, confirmar seleção, interpretar resultados e decidir. Liga esta aula a jobs e dependências, incidentes, evidência de artefactos e gestão de releases.
python3 content/labs/cicd-results/run.py --output /tmp/dr-cicd-results-first.json
# Choose a new output path; existing output files are not overwritten.
# CPython 3.13.1 was executed; see the recorded environment.
# wrong-pattern-empty-suite: exitCode=0, testsRun=0
# skip-outcome: exitCode=0, passedIds=[]
# expected-outcome: exitCode=0, expectedFailures contains one ID
# unexpected-outcome: exitCode=1
# These are actual local unittest results, not hosted CI execution.Num batch fictício, uma mudança de diretório deixa a pipeline verde com zero testes. A reconciliação exigida continua sem evidência.
Armadilhas comuns
Contar skips como testes aprovados, usar uma falha esperada como dispensa funcional ou compensar um teste crítico perdido com verificações irrelevantes.
Tópicos relacionados: Contratos entre jobs · Evidência de testes · Gestão de releases
Um runner bem-sucedido só responde segundo a sua semântica. A entrega precisa de uma política que confirme os comportamentos relevantes no contexto certo.
Referência: unittest: discovery, outcomes and test results · CI/CD practices 2026-09; scoped GitHub Actions GitLab Jenkins and Azure DevOps Services documentation