Les builders de données de test avec valeurs par défaut réduisent la casse des tests lorsqu'un objet du domaine change

Hypothèse

Un Object Mother, dans la description de Fowler, est une fabrique qui renvoie des objets toujours identiques et familiers (« John, embauché la semaine dernière »), partagés entre de nombreux tests ; il désigne comme défaut le couplage lourd qui en résulte, car de nombreux tests dépendent des données exactes de la Mother, ce qui rend leur modification délicate. Un builder de données de test adopte la posture inverse : il part d'un objet par défaut valide et expose une méthode par champ, de sorte que an_order().with_status("paid").with_lines(3).build() énonce exactement les champs dont dépend le test, et hérite de tout le reste. L'hypothèse : lorsqu'un champ obligatoire est ajouté à un objet du domaine, qu'une signature de constructeur change ou qu'une règle de validation se resserre, les suites fondées sur des builders n'ont besoin de modifications qu'à un seul endroit (les valeurs par défaut du builder), tandis que les suites qui construisent les objets directement, chargent des fixtures partagées ou dépendent d'instances toutes faites d'une Mother ont besoin de modifications proportionnelles au nombre de tests qui touchent l'objet. Une affirmation secondaire concerne la lisibilité : les champs nommés dans un test de style builder sont précisément ceux dont dépend l'assertion, si bien qu'un lecteur n'a pas besoin de comparer le test à un fichier de fixtures.

Prédiction

Dans l'historique des versions, les commits qui ajoutent un champ obligatoire à une entité ou changent son constructeur touchent moins de fichiers de test, normalisé par le nombre de tests qui utilisent l'entité, dans les bases de code où l'entité est construite via un builder que dans les bases de code utilisant une construction directe, des fichiers de fixtures ou un Object Mother. Des relecteurs à qui l'on demande « de quels champs ce test dépend-il ? » répondent plus vite et avec plus de précision pour les tests de style builder.

Test proposé

1. Sélectionner des dépôts dans lesquels les deux styles coexistent, ou une même base de code avant et après l'introduction de builders pour un ensemble d'entités.
2. Identifier les commits qui ajoutent un champ obligatoire ou changent un constructeur ; compter les fichiers de test modifiés et les lignes de test modifiées par commit, groupés par style de construction, et normaliser par le nombre d'usages.
3. Pour l'affirmation sur la lisibilité, donner à des relecteurs des paires appariées de tests (même comportement, les deux styles) et chronométrer l'identification des champs dont dépend l'assertion.

Statut

Aucun résultat n'est revendiqué. Les builders coûtent une classe par entité et peuvent masquer les valeurs par défaut sur lesquelles un test s'appuie silencieusement ; les Object Mother conservent leur valeur pour des exemples partagés et nommés qui apparaissent dans les conversations avec les utilisateurs. L'hypothèse porte sur le nombre de modifications lors d'un changement et sur la lisibilité, pas sur la détection de défauts.