Comment tester les méthodes de la racine agrégée qui délègue juste son appel à l'entité AR?

Question

Pour apporter un exemple précis, je PromoCode racine globale qui se compose de PromoCodeUsage entité qui est uniquement contrôlée par cette AR, de sorte que certaines méthodes sur AR sont simplement déléguées à cette entité, comme:

public function useFor(Order $order): void 
{ 
    $this->promoCodeUsage->useFor($order); 
} 

Et certains d'entre eux sont en partie déléguée, comme:

public function applyFor(Order $order): void 
{ 
    if (!$this->published) { 
     throw new NotPublishedPromoCodeCanNotBeApplied(); 
    } 

    $this->promoCodeUsage->applyFor($order); 
} 

Ma suite de tests couvre entièrement tous les comportements PromoCode y compris PromoCodeUsage fonctionnalité, car à cette itération il n'y avait pas PromoCodeUsage et la logique a été mélangé à PromoCode. Puis j'ai refacturé une partie de cette logique en PromoCodeUsage. Cette suite de tests pour PromoCode a eu de nombreux tests et j'étais heureux de pouvoir le diviser aussi (mais ça a bien fonctionné même après avoir séparé des entités). J'ai donc créé une autre suite de tests (PromoCodeUsageTest), où j'ai déplacé une partie des tests de PromoCode.

Mais PromoCodeUsageTest s testent l'entité PromoCodeUsage par le biais du comportement de PromoCode, de la même manière que dans le test d'origine avant la division. Ils ne touchent pas PromoCodeUsage directement. Maintenant, j'ai PromoCodeTest suite avec: et suite PromoCodeUsageTest avec:

Mais il est en quelque sorte bizarre, que 1) PromoCodeTest Je laisse de côté certains tests (qui sont d'ailleurs) et 2) PromoCodeUsageTest Je suis en fait pas touchant PromoCodeUsage entité. 3) J'utilise le modèle de Roy Osherove pour le nommage des tests, et je ne sais pas quel nom de méthode dois-je utiliser dans le nom du test - à partir de PromoCode ou de PromoCodeUsage? Dans mon cas, ils sont identiques, mais ils pourraient différer et cette idée sent.

Si je réécris PromoCodeUsageTest s pour tester directement l'entité PromoCodeUsage, je me retrouve avec des méthodes non couvertes sur PromoCode (qui sont simplement déléguées à PromoCodeUsage). Donc, cela me ramène à mon approche pour tester PromoCodeUsage à PromoCode AR. Oncle Bob (et autres) dit que c'est une bonne habitude de tester le comportement, pas API. Mon approche est-elle conforme à cela? Parce que je sens de l'odeur dans mon approche, n'est-ce pas? Comment faire mieux?

Answer 1

Vous avez raison de penser au comportement de test. Je suppose que tout le comportement de votre agrégat est exposé à travers la racine agrégée, il est donc logique de tester à travers la racine. Je vous suggère simplement de nommer vos tests pour décrire le comportement qu'ils testent. N'utilisez pas de noms de méthode dans les noms de test, car ceux-ci pourraient changer - ceci lie vos noms de test à l'implémentation interne de votre code de production.

Si une classe de test devient très volumineuse, il est logique de la diviser en classes plus petites - il n'y a aucune règle selon laquelle vous devez avoir une relation 1: 1 entre les classes de test et de production. Cependant, cela peut suggérer que votre classe, et votre agrégat dans ce cas, pourrait avoir trop de responsabilités et pourrait être divisée en plus petites parties.

Answer 2

J'ai tendance à voir des Agrégats comme des machines à états et à les tester en conséquence.Ce qui importe, ce n'est pas le test dans le fichier de test, mais le test de tous les états résultants de l'agrégat PromoCode en fonction de l'état de départ et du type d'utilisation/application du code promotionnel que vous utilisez.

Bien sûr, cela peut nécessiter de regarder au plus profond de l'intégrité de l'agrégat, dans les entités dépendantes. Si vous êtes plus à l'aise de mettre dans une classe de test différente tous les tests dont les Asserts regardent PromoCodeUsage par exemple, alors bien, tant que les noms de test reflètent le domaine et pas quelques détails techniques.