Suíte de testes cega
A suíte é evidência independente derivada do contrato, não a definição de conformidade; portanto, um teste que falha indica que a implementação ou o teste está errado, nunca o contrato.
test-writer decide a forma de cada teste e test-oracle-reviewer o que conta como um valor independente; esta skill é o isolamento em torno deles.
O que o autor vê
O arquivo do contrato, a interface contra a qual ele é escrito (o crate ou módulo do contrato, seus tipos e documentação), e fontes publicadas: especificações, vetores de teste com origem controlada (vendored), capturas. Não vê uma implementação, uma implementação anterior ou o pull request que produziu o contrato, porque cada um carrega uma leitura do contrato que a suíte confirmaria em vez de testar. Quando uma implementação existe, o autor está em um contexto novo em uma árvore de trabalho em um commit sem ela; uma lista de não-leitura complementa isso e não o substitui, já que um contexto que viu a implementação não pode desvê-la.
Valores esperados
De uma fonte publicada citada no teste, uma propriedade que o contrato afirma, ou uma derivação cujo método o contrato ou um padrão citado fixa, registrado junto ao vetor para que um revisor possa refazê-lo; nunca de um cálculo que apenas uma implementação do contrato poderia realizar, porque verificar tal valor significa implementar o contrato novamente. Um vetor derivado contabiliza cada campo acoplado que a alteração toca – comprimento, checksum, assinatura – ou seu resultado não é o que a derivação alega. Onde não existe resposta publicada, compare saídas entre implementações; uma verificação diferencial nunca fica sozinha, porque um bug compartilhado por ambas passa por ela. Uma entrada negativa escrita à mão difere de um controle independentemente válido apenas na dimensão alvo, para que o teste possa falhar apenas pela razão que nomeia; uma regra que nomeia uma entrada rejeitada ganha uma, já que tal regra testada apenas por aceitação é cumprida por aceitar tudo. Fontes com origem controlada (vendored) mantêm origem, versão e checksum registrados, são tomadas integralmente ou cortadas em seus próprios limites de seção, e nunca são editadas, porque um vetor editado ou fatiado perde a proveniência que o torna um oráculo. Mantenha um registro de cobertura ao lado da suíte: qual teste verifica cada cláusula, quais cláusulas são verificadas apenas por revisão e os limites deliberadamente deixados sem verificação, para que o silêncio não seja tomado como cobertura.
Revisão e merge
O revisor executa test-reviewer e verifica o contrato contra o registro de cobertura em ambos os sentidos: toda cláusula tem um teste ou uma lacuna registrada, todo teste cita sua cláusula.
Escreva a suíte antes da implementação; faça o merge dela assim que uma implementação a executar verde, para que um teste que nenhuma implementação conforme pode passar seja encontrado antes de ele vincular todas as posteriores.
Somente leitura durante a implementação
Um pull request de implementação nunca edita a suíte ou o contrato. Um teste que parece errado, ou uma cláusula sem teste, é escalado com o vetor ou cláusula, valores esperados e observados, e a fonte citada. A correção vai para o pull request que possui a suíte – o aberto, por meio de seu líder, ou um novo assim que ele tiver feito merge – por um autor novo com as mesmas entradas, que recebe a decisão e não a saída da implementação, para que a suíte permaneça cega.