Suite de tests aveugle
La suite constitue une preuve indépendante dérivée du contrat, et non une définition de la conformité : un échec indique que l'implémentation ou le test est erroné, jamais le contrat.
Le test-writer décide la forme de chaque test et le test-oracle-reviewer ce qui constitue une valeur indépendante ; cette compétence constitue l'isolation autour d'eux.
Ce que voit l'auteur
Le fichier de contrat, l'interface sur laquelle il est rédigé (le crate ou module du contrat, ses types et sa documentation), et les sources publiées : spécifications, vecteurs officiels, captures. Pas d'implémentation, d'implémentation antérieure ou de pull request ayant produit le contrat, car chacun porte une lecture du contrat que la suite confirmerait plutôt que de tester. Lorsqu'une implémentation existe, l'auteur est un contexte frais dans un arbre de travail à un commit sans elle ; une liste de documents à ne pas lire complète cette règle et ne la remplace pas, car un contexte qui a vu l'implémentation ne peut pas la désapprendre.
Valeurs attendues
Issues d'une source publiée citée dans le test, d'une propriété énoncée par le contrat, ou d'une dérivation dont la méthode est fixée par le contrat ou la norme citée, enregistrées à côté du vecteur afin qu'un relecteur puisse la refaire ; jamais issues d'un calcul que seule une implémentation du contrat pourrait effectuer, car vérifier une telle valeur revient à implémenter à nouveau le contrat. Un vecteur dérivé tient compte de tous les champs couplés que la modification touche — longueur, somme de contrôle, signature — sinon son résultat n'est pas celui que la dérivation prétend. Lorsqu'aucune réponse publiée n'existe, comparer les sorties entre implémentations ; une vérification différentielle ne se suffit jamais à elle-même, car un bogue partagé par les deux la ferait réussir. Une entrée négative écrite à la main diffère d'un témoin indépendamment valide uniquement dans la dimension ciblée, de sorte que le test ne peut échouer que pour la raison qu'il nomme ; une règle qui nomme une entrée rejetée en obtient une, car une telle règle testée uniquement par l'acceptation est satisfaite en acceptant tout. Les sources vendues conservent leur origine, leur version et leur somme de contrôle enregistrées, sont prises en entier ou coupées à leurs propres limites de section, et ne sont jamais modifiées, car un vecteur édité ou tronqué perd la provenance qui en fait un oracle. Tenir un registre de couverture à côté de la suite : quel test vérifie quelle clause, quelles clauses sont vérifiées par relecture uniquement, et les limites délibérément laissées non testées, afin que le silence ne soit pas pris pour de la couverture.
Révision et fusion
Le relecteur exécute test-reviewer et vérifie le contrat par rapport au registre de couverture dans les deux sens : chaque clause a un test ou un écart documenté, chaque test cite sa clause.
Rédiger la suite avant l'implémentation ; la fusionner une fois qu'une implémentation la passe au vert, de sorte qu'un test qu'aucune implémentation conforme ne peut passer soit découvert avant qu'il ne lie toutes les suivantes.
Lecture seule pendant l'implémentation
Une pull request d'implémentation ne modifie jamais la suite ni le contrat. Un test qui semble erroné, ou une clause sans test, est escaladé avec le vecteur ou la clause, les valeurs attendues et observées, et la source citée. La correction va à la pull request propriétaire de la suite — celle en cours via son responsable, ou une nouvelle une fois fusionnée — par un auteur frais avec les mêmes entrées, qui reçoit la décision et non la sortie de l'implémentation, afin que la suite reste aveugle.