Utilisez les tests comme preuves

Partez de l’exigence

Les tests apportent des preuves pour des affirmations précises. Une exécution réussie ne démontre pas toutes les propriétés du logiciel. Avant de demander des tests, identifiez le comportement important et le défaut que chaque contrôle doit détecter.

Pour un export fictif par organisation, l’exigence principale est l’isolation des données. Un utilisateur de l’organisation A ne doit pas recevoir les enregistrements de l’organisation B. Un test qui vérifie seulement la réussite du téléchargement ne démontre pas cette exigence.

Demandez à l’agent d’expliquer le lien entre l’exigence et l’assertion. Cela aide à repérer les cas manquants avant que la suite de tests ne devienne volumineuse.

Choisissez le bon périmètre de test

Un test unitaire peut vérifier rapidement une petite transformation. Un test d’intégration peut vérifier la coopération entre composants. Un test de bout en bout peut vérifier un parcours utilisateur important dans l’application déployée ou dans une version représentative.

Utilisez le périmètre le plus restreint qui fournit les preuves nécessaires. Un outil de formatage n’a pas besoin d’un test complet dans le navigateur pour chaque entrée. Une limite d’autorisation peut nécessiter une route réelle et le chemin d’accès aux données. Une interaction critique dans le navigateur exige des preuves sur l’interface rendue.

Aucune répartition fixe des types de tests ne convient à tous les systèmes. Choisissez selon la défaillance à détecter et le coût de maintenance du contrôle.

Évitez une hypothèse erronée commune

Un agent peut écrire l’implémentation et les tests à partir de la même mauvaise compréhension. Les deux peuvent être cohérents entre eux alors que l’exigence reste insatisfaite.

Supposons que l’implémentation filtre les enregistrements selon l’identifiant d’organisation fourni dans la requête. Le test utilise le même identifiant pour l’utilisateur connecté et la requête. Il réussit. Le cas absent est celui d’un utilisateur qui demande l’identifiant d’une autre organisation.

Ajoutez ce cas en passant par le véritable chemin d’identité de confiance et d’autorisation. Un mock qui répond toujours « autorisé » ne démontre pas l’isolation des tenants. Il vérifie uniquement le comportement après une autorisation réussie.

Vérifiez que le test peut échouer

Pour un défaut connu, exécutez le nouveau test de régression sur la version défectueuse dans une branche isolée. Confirmez qu’il échoue pour la raison attendue. Appliquez ensuite la correction et relancez-le.

Un test qui échoue parce qu’une fixture ne peut pas se charger ne fournit pas encore de preuve sur le comportement métier. Inspectez l’échec, pas seulement le code de sortie.

Pour des modifications plus larges, les tests par mutation peuvent aider à vérifier si certaines modifications du code font échouer les tests. Ils ont un coût et ne remplacent pas la revue des exigences. Utilisez-les lorsque ces preuves supplémentaires soutiennent une décision importante.

Reliez les preuves à la modification

Exécutez les contrôles pertinents sur la révision finale. Consignez les contrôles omis et leurs raisons. Un résultat obtenu sur un commit antérieur peut ne plus s’appliquer après une correction de revue.

Gardez les tests compréhensibles. Préférez une préparation et une assertion explicites à une grande fonction auxiliaire qui masque la condition importante. Supprimez les contrôles redondants lorsqu’ils ajoutent un coût de maintenance sans détecter une défaillance différente.

La personne qui examine la modification doit pouvoir dire ce que les tests établissent et ce qui reste incertain. Cette explication est plus utile qu’un grand nombre de tests.