Faire écrire les tests d'un incrément, avant sa construction

Quand l’employer

À employer juste après la spécification et avant la construction, avec un agent distinct de celui qui construira. À ne pas employer avec l'agent constructeur : il écrirait les tests que son code passe.

Les 4 trous à remplir avant d’envoyer

Chaque trou est une décision déjà prise. Un trou que vous ne savez pas remplir n’est pas une case à improviser : c’est un travail de cadrage qui manque.

{COMPORTEMENT_A_COUVRIR}

Quel comportement précis les tests doivent-ils garder, formulé du point de vue de l'usage ?

Pourquoi ce trou existe. Des tests écrits à partir du code vérifient que le code fait ce qu'il fait. Écrits à partir de l'usage, ils vérifient qu'il fait ce qu'on attend.

Si vous ne savez pas répondre. Reprenez les critères d'acceptation de la spécification. S'il n'y en a pas, il n'y a rien à tester : c'est la spécification qui manque.

{CAS_QUI_DOIVENT_ECHOUER}

Quels usages doivent être refusés par le système, et avec quel message ?

Pourquoi ce trou existe. Un jeu de tests qui ne vérifie que les cas heureux laisse passer exactement les défauts qui coûtent cher : ceux des cas malheureux.

Si vous ne savez pas répondre. Prenez chaque règle métier et demandez ce qui se passe quand elle est violée. Chaque violation est un test à écrire.

{DONNEES_DE_TEST}

Sur quelles données les tests travaillent-ils, et d'où viennent-elles ?

Pourquoi ce trou existe. Des tests qui touchent des données réelles finissent par envoyer un courriel à un vrai client. Des tests sans données ne prouvent rien.

Si vous ne savez pas répondre. Exigez des données fabriquées à l'intérieur du test, jamais une base partagée et jamais un extrait de production.

{CE_QUI_NE_SE_TESTE_PAS_ICI}

Quelles parties sont hors du champ de ces tests, et pourquoi ?

Pourquoi ce trou existe. Un agent à qui l'on demande des tests sans bornes en écrit des centaines, qui deviennent trop longs à exécuter et que plus personne ne lit.

Si vous ne savez pas répondre. Excluez tout ce qui n'est pas la règle que vous voulez protéger : l'apparence, la vitesse, les services extérieurs.

Le corps du gabarit

Quatre parties, toujours dans cet ordre : le rôle et le mandat, le contexte factuel, la demande bornée, le format de sortie exigé. Les trous restent visibles à la copie, et c’est voulu : les remplir un par un est la dernière occasion de s’apercevoir qu’une décision manque.

## 1. RÔLE ET MANDAT

Tu es responsable de la vérification, et tu n'es pas celui qui construira. Ton mandat est d'écrire les tests qui diront si le travail à venir est conforme. Tu écris ces tests à partir de la règle attendue, jamais à partir d'un code existant.

## 2. CONTEXTE FACTUEL

Comportement à garder : {COMPORTEMENT_A_COUVRIR}
Usages qui doivent être refusés : {CAS_QUI_DOIVENT_ECHOUER}
Données sur lesquelles les tests travaillent : {DONNEES_DE_TEST}
Hors champ de ces tests : {CE_QUI_NE_SE_TESTE_PAS_ICI}

Le code de l'incrément n'existe pas encore, ou tu fais comme s'il n'existait pas. Un test écrit après lecture du code épouse le code, y compris ses défauts.

## 3. DEMANDE BORNÉE

Écris les tests, pas l'implémentation.

Ce que je veux :
1. la liste des cas testés, en français, avant tout code : un cas par ligne, énoncé comme une phrase vraie ou fausse ;
2. pour chaque cas, s'il vérifie un succès attendu ou un refus attendu ;
3. le code des tests, chacun portant le nom du cas qu'il vérifie ;
4. les données de test fabriquées à l'intérieur des tests ;
5. les cas que tu as jugés impossibles à tester et la raison ;
6. la commande exacte qui exécute ces tests seuls.

Ce que je ne veux pas : l'implémentation qui les ferait passer, un test qui vérifie l'apparence, un test dépendant d'un service extérieur, un test qui lit une base partagée, un test qui passe quel que soit le comportement.

## 4. FORMAT DE SORTIE EXIGÉ

La liste des cas en français précède le code. Chaque refus attendu vérifie le message exact, pas seulement le fait de l'échec. Les tests doivent échouer aujourd'hui, puisque le code n'existe pas : tu me dis lesquels doivent échouer et avec quel message.

Ta réponse est refusable si un test passe alors que le code n'existe pas, si un test dépend d'un service extérieur, ou si la liste en français manque.

Ce que vous devez recevoir

• Une liste des cas testés en français, un par ligne, avant tout code.
• Pour chaque cas, la mention succès attendu ou refus attendu.
• Des tests nommés par le cas qu'ils vérifient, pas par la fonction qu'ils appellent.
• Des données de test fabriquées dans le test lui-même.
• La vérification du message exact pour chaque refus attendu.
• La commande qui exécute ces tests seuls, et le constat qu'ils échouent aujourd'hui.

Ce qui doit vous faire refuser

Ces motifs sont écrits comme des constats : « un fichier hors périmètre a été modifié » se vérifie, « le travail manque de rigueur » ne se vérifie pas.

• Un test passe alors que le code censé le satisfaire n'existe pas encore.
• L'agent a livré l'implémentation en même temps, ce qui annule la valeur du test.
• Un test dépend d'un service extérieur, donc échouera un jour sans rapport avec le code.
• Un test lit ou écrit dans une base partagée, ce qui contamine les autres tests.
• Un refus attendu est vérifié par le seul fait de l'échec, sans contrôler le message.
• La liste des cas en français manque, ce qui vous empêche de juger la couverture.

Selon pour qui vous construisez

Pour moi.

Employez un agent distinct de celui qui construira, même si c'est le même produit : ouvrez une conversation neuve, sans l'historique de la construction.

Pour mon employeur.

La liste des cas en français se relit avec le commanditaire. C'est le seul document technique qu'il peut juger sans aide.

Pour un client.

La liste des cas et le résultat de leur exécution constituent la preuve remise avec le livrable. Sans elle, votre recette repose sur la parole.