Aller au contenu

Stratégie de tests du Product Domain

Statut

Spécification normative de qualité.

Pourquoi cette page existe

Les tests servent à vérifier que les règles fondamentales du Product Domain restent vraies lorsque le code évolue.

Pour une personne qui reprend le projet, ils jouent aussi un rôle de filet de sécurité : avant de modifier une règle d'identité, de variante ou de conflit, les tests permettent de voir ce que le système garantit déjà.

Règle centrale

Les tests doivent protéger les invariants métier avant les détails techniques.

Les invariants principaux sont notamment :

  • une identité canonique unique ;
  • un Identifier reste une preuve ;
  • une Observation ne remplace pas silencieusement l'identité ;
  • une Variant appartient à un seul Product.

Les différentes couches de tests

Tests unitaires

Ils vérifient une petite unité de logique isolée :

  • Value Objects ;
  • Specifications ;
  • règles d'invariants ;
  • cas simples de Policies.

Ils doivent être rapides et ne pas nécessiter WordPress ou une base de données.

Tests du domaine

Ils vérifient le comportement du Product Aggregate :

  • construction et évolution d'un Product ;
  • gestion des conflits ;
  • attachement des observations ;
  • gestion des variantes ;
  • résolution d'identité.

Tests des Domain Services

Ils couvrent les opérations plus transversales :

  • résolution d'identité ;
  • fusion de Products ;
  • séparation d'un Product ;
  • résolution de conflits ;
  • évaluation de cohérence.

Pourquoi ne pas utiliser la production comme test ?

Tester une règle en modifiant directement des Products réels est dangereux et rend le diagnostic difficile.

La séquence correcte est :

Cas reproductible
      ↓
Test automatisé
      ↓
Modification du code
      ↓
Tests verts
      ↓
Audit / simulation si nécessaire
      ↓
Déploiement contrôlé

Déterminisme

Un test du domaine doit produire le même résultat à chaque exécution avec les mêmes entrées.

Il ne doit pas dépendre :

  • de l'heure actuelle sans la fournir explicitement ;
  • d'un ordre aléatoire ;
  • d'un appel réseau ;
  • d'une donnée de production changeante.

Tester les cas difficiles

Il ne suffit pas de tester uniquement les cas où tout fonctionne.

Il faut également couvrir :

  • données manquantes ;
  • identifiants contradictoires ;
  • observations incompatibles ;
  • variantes mal rattachées ;
  • faible confiance ;
  • conflits non résolus ;
  • tentative de fusion non justifiée.

Ces cas protègent le projet contre les erreurs les plus coûteuses.

Avant de modifier le Product Domain

Pour une modification importante :

  1. identifier l'invariant ou la règle concernée ;
  2. chercher les tests existants ;
  3. ajouter un test qui reproduit le comportement attendu ou le bug ;
  4. modifier le code ;
  5. exécuter les tests ciblés ;
  6. exécuter ensuite la suite plus large prévue par le projet ;
  7. mettre à jour la documentation si le contrat change.

Ce que les tests du domaine ne doivent pas nécessiter

Les tests métier du Product Domain doivent autant que possible fonctionner sans :

  • MariaDB ;
  • WordPress ;
  • Docker ;
  • feed marchand distant ;
  • frontend.

Les tests d'intégration existent pour vérifier les assemblages techniques, mais ils ne remplacent pas les tests métier isolés.

Lire un échec de test

Un test rouge n'indique pas automatiquement que le test est mauvais.

Commence par déterminer :

  • quel invariant il protège ;
  • quelles entrées ont été utilisées ;
  • quel résultat était attendu ;
  • ce que la modification actuelle a changé.

Ne supprime ou n'assouplis jamais un test uniquement pour obtenir une suite verte sans comprendre la règle qu'il protège.

Décision

La stratégie de tests protège d'abord la cohérence du Product Domain, puis les détails d'intégration.

Voir aussi