Conceito e mecanismo
Integrar testes numa pipeline exige mais do que executar um comando. O resultado deve identificar a versão do produto, a versão dos testes, a configuração relevante e os dados usados. Se a pipeline testa uma compilação e promove outra, a ligação entre evidência e release fica comprometida. Confirma também como falhas são propagadas: produzir um relatório HTML não garante que a etapa termina com estado de erro. Uma tarefa posterior de publicação de relatórios deve conservar o resultado dos testes. Dependências de preparação precisam de ficar explícitas para evitar executar verificações sobre um ambiente incompleto. Em Playwright, projetos dependentes não avançam quando o projeto de preparação falha; a aplicação concreta deste mecanismo deve ser compreendida pela equipa.
Aplicação guiada
Num serviço de posições, um consumidor espera um campo numérico e o fornecedor passa a devolver texto. Um teste de contrato pode detetar a incompatibilidade entre as expectativas do consumidor e a resposta do fornecedor. Não demonstra, por si só, desempenho sob carga nem todos os efeitos de negócio internos. Mantém outras verificações para esses riscos. Para feedback rápido, distribui verificações por etapas adequadas ao custo e ao risco, sem promover resultados parciais como cobertura completa. Se várias partes da suite correm em paralelo, recolhe os resultados de todas as partes esperadas e confirma que pertencem à mesma execução. Um relatório combinado incompleto pode parecer verde porque faltam precisamente as partes que falharam.
Artefacto, testes e configuração devem estar ligados à mesma evidência.
Armadilhas comuns
Relatório como exit status; compilação diferente promovida; contrato como prova de desempenho.
Tópicos relacionados: Objetivo e âmbito da automação · Testabilidade e avaliação de ferramentas · Arquitetura, camadas e dados
Preserva proveniência e propaga falhas até à decisão.
Referência: Playwright Continuous integration · CTAL-TAE v2.0 (2024)