Nesta página
O que cada tipo de teste pode demonstrar
Uma propriedade é verificada no nível que consegue enxergá-la. Um teste unitário não enxerga um deploy; um teste de admissão não enxerga a resposta de um modelo. A tabela indica, para cada nível, o que ele prova, o que não consegue provar e onde o Companion o usa.
| Nível | Prova | Não consegue provar | Usado para |
|---|---|---|---|
| Teste unitário | Um componente recusa o que precisa recusar | Que o componente está no caminho | Esquemas de fronteira, fábricas de verificação, regras de política |
| Teste de arquitetura | O grafo de dependências não tem nenhuma aresta proibida | Caminhos de dados que não são importações | Fronteira probabilística, isolamento de normas |
| Teste de contrato | Os dois lados concordam sobre um formato, incluindo a procedência exigida | Que os dois lados estão implantados em versões compatíveis | Contratos de proposta e de decisão |
| Teste de integração | A propriedade vale contra a dependência real | O comportamento sob outra configuração | Privilégios da trilha de auditoria, propagação de contexto, versões de política |
| Teste de ponta a ponta | Um estado proibido não consegue chegar a uma saída | Caminhos que o teste não exercita | Valores não verificados, o fence de publicação |
| Teste de deploy ou de admissão | A plataforma recusa uma carga de trabalho que quebra uma regra | Qualquer coisa dentro da carga de trabalho | Imagens fixadas, versões nomeadas, isolamento de rede |
| Evidência manual | Uma pessoa com nome executou um procedimento escrito | Que ele será executado de novo | Revisões de licença, reexecuções de decisões históricas |
As duas direções: o caminho positivo e a prova de dentes
Toda propriedade no Companion tem uma verificação positiva (passar é assim) e uma negativa (este defeito, plantado, é recusado). Uma suíte só com a metade positiva pode ter todas as restrições apagadas e continuar verde. É a metade negativa que mostra que a verificação está no caminho.
Os cinco passos de uma prova de dentes estão na página Fences executáveis, e o perfil de Python e FastAPI os executa: uma importação plantada quebra um contrato, uma restrição apagada deixa um teste vermelho, um sentinela plantado faz o fence de publicação falhar, e cada restauração é comparada byte a byte.
Contar o que rodou
Um resultado não é “verde”. É: quais verificações rodaram, quantas asserções foram executadas, em qual execução identificada, com qual desfecho. O modelo de relatório de controles do COADF diz o mesmo sobre controles: uma verificação pulada, um sucesso anterior ou uma seleção que não rodou teste nenhum não é verificação atual.
- Uma seleção de testes que não casa com nada pode ter sucesso. A contagem precisa ser afirmada.
- Um teste pulado por falta de banco de dados não é um teste que passou. Ele deve ser relatado como não executado.
- Um job pulado pode ser relatado como bem-sucedido. É preciso exigir a verificação que não pode ser pulada.
Quando uma pessoa é o controle
Alguns controles são sustentados por uma pessoa que executa um procedimento escrito: uma revisão de licença, uma reexecução de decisões históricas amostradas, uma decisão no merge. Eles devem ser relatados como manuais, com o nome da pessoa e o procedimento, nunca como automatizados. Um controle manual relatado com honestidade vale mais que um automatizado relatado com frouxidão.
O que a verificação não estabelece
Testes estabelecem que testes passaram. Eles não estabelecem conformidade regulatória, certificação nem avaliação da conformidade, e uma suíte completa para cada propriedade deste Companion também não estabelece nada disso. Guardiões automáticos sobre texto e código são necessários e não suficientes: eles não enxergam um mecanismo expresso por fluxo de controle, identificadores renomeados ou a geometria de um diagrama, e a revisão humana continua fazendo parte da verificação.