Je lis que vous pensez que les tests unitaires, tout comme les objets SOLIDES, doivent avoir "une raison de casser". C'est un objectif noble, mais je pense que vous constaterez que dans de nombreux cas, il n'est tout simplement pas réalisable. Un de ces cas est ici, où vous avez un objet de domaine "riche" (DDD différencie les entités et les objets de valeur, qui comprennent tous les deux le "modèle de domaine") qui est une dépendance du système testé.
Dans ces situations, j'ai la philosophie que, étant donnél'objet de domaine a sa propre couverture de test unitaire complète, en espérant que l'objet fonctionnera comme prévu dans un test unitaire pour un SUT différent ne viole pas nécessairement le test unitaire. Si ce test venait à échouer en raison d'une rupture dans le domaine, je m'attendrais à ce que le test unitaire de l'objet domaine se casse également, ce qui m'amènerait vers quelque chose à enquêter. Si le test unitaire de l'objet de domaine a été correctement mis à jour en tant que test rouge, puis est devenu vert avec le changement, et cet autre test a ensuite échoué, ce n'est pas nécessairement une mauvaise chose non plus; cela signifie que les attentes de cet autre test sont en conflit avec les nouvelles attentes pour le domaine, et je dois m'assurer que les deux sont en accord les uns avec les autres et avec les critères d'acceptation généraux du système.
En tant que tel, je ne me moquerais d'un objet de domaine que si ledit objet de domaine produisait des "effets secondaires" qui n'étaient pas souhaitables du point de vue des tests unitaires (c'est-à-dire toucher des ressources externes comme des magasins de données), ou si la logique de l'objet de domaine était suffisamment complexe pour le placer dans l'état approprié pour le test devient un obstacle à la définition et à la réussite du test.
Cela devient alors la question déterminante; qui est plus facile? Pour utiliser l'objet de domaine à sa destination dans le test, ou pour se moquer de lui? Faites ce qui est le plus facile, jusqu'à ce que ce ne soit plus l'option la plus facile, comme lorsqu'un changement fonctionnel rompt le test du service de manière complexe; si cela se produit, réécrivez le test pour produire une maquette qui expose les exigences fonctionnelles dont dépend le service, sans la complexité qui le rompt.
Comprenez que dans les deux cas, il devrait y avoir un test d'intégration qui utilise l'objet de domaine réel connecté au service réel qui teste l'interaction entre ces deux à un niveau d'abstraction plus élevé (comme le test, par exemple, non seulement la fonctionnalité derrière un service mais un proxy à travers lequel l'objet de domaine est sérialisé et envoyé).