Construire des données de test avec des builders : valeurs par défaut valides, écarts nommés

Objectif

Des tests dont la mise en place ne nomme que les valeurs pertinentes pour le contrôle, et qui, lors de changements du modèle de données, ne sont ajustés qu'à un seul endroit.

Prérequis

Des entités avec des règles de validité claires (quels champs sont obligatoires, quelles combinaisons sont autorisées) ; un langage permettant d'exprimer des appels chaînés ou des arguments nommés ; un cadre de test capable de construire les objets sans base de données, ou avec une base de données jetable.

Étapes

1. Pour chaque entité qui apparaît dans plus d'une poignée de tests, créer un builder : eine_bestellung() fournit une commande valide avec des valeurs par défaut sensées (un article, statut « ouvert », client renseigné).
2. Une méthode de définition nommée par champ (.mit_status("bezahlt"), .mit_positionen(3)), ou — dans les langages à arguments nommés — une fonction avec des valeurs par défaut. Le builder ne crée l'objet qu'au moment de .bauen().
3. Dans le test, ne définir que ce qui concerne l'assertion : un test sur les relances définit l'échéance et le statut, rien d'autre. Ce qui n'est pas nommé est sans importance pour le test — c'est la règle de lecture.
4. Éviter le hasard ou le figer : les valeurs par défaut sont déterministes ; là où l'unicité est nécessaire (adresse e-mail), un compteur plutôt que le hasard.
5. Construire les objets liés via d'autres builders (.mit_kundin(eine_kundin().aus_land("CH"))), afin que les relations restent valides.
6. Lors d'un changement du modèle (nouvelle colonne obligatoire, constructeur modifié), adapter d'abord le builder, puis lancer les tests ; seuls les tests concernés sur le fond par le nouveau champ sont touchés.
7. Ne garder des objets « canoniques » partagés (le client Meier, qui revient toujours) que là où ils constituent un vocabulaire commun avec les personnes du métier — et les créer eux aussi via le builder.

Résultat attendu

Un test se lit comme « étant donné une commande au statut payé et trois lignes, quand…, alors… » ; les changements de modèle produisent des ajustements de test peu nombreux et locaux ; les fichiers de fixtures de plusieurs centaines de lignes disparaissent.

Limites et base de vérification

Le motif se distingue de l'Object Mother, que Martin Fowler décrit comme une fabrique d'objets d'exemple familiers et déjà prêts, et dont il désigne le défaut comme un couplage étroit : de nombreux tests dépendent des données exactes de la Mother, ce qui rend leur modification délicate. Un builder par entité coûte en maintenance et peut masquer sur quelles valeurs par défaut un test s'appuie silencieusement. Que les builders réduisent réellement le nombre de modifications de tests est formulé dans le wiki comme une hypothèse à part, pas comme un constat ; aucune mesure n'est revendiquée.