Quand dois-je utiliser des objets fantaisie?


14

J'ai lu beaucoup de choses sur TDD mais j'ai encore des doutes. Par exemple, j'ai ces diagrammes de classes:

entrez la description de l'image ici

C'est un exemple simple, juste pour en savoir plus sur TDD et les objets fictifs.

Quel test dois-je passer en premier? Produit , puis Ligne et dernier, Commande ? Si je le fais, dois-je utiliser la ligne et le produit pour tester la commande ou dois-je utiliser des objets fantômes? Quand dois-je utiliser des objets fantômes? Dois-je utiliser UML avec XP et TDD?

Je n'ai pas encore ces choses.

Réponses:


10

À en juger par le diagramme, le produit est une classe de données stupide, sans fonctionnalité à tester. Je commencerais donc à écrire des tests pour (et à implémenter, le style TDD) d'abord Line puis Order, dans l'échelle de dépendance. Il est généralement judicieux de faire tester vos classes de niveau inférieur avant de commencer à travailler sur des classes de niveau supérieur (c'est-à-dire qui dépendent du niveau inférieur). Cela rend la capture de bogues plus efficace.

La nécessité d'utiliser des objets fantaisie dépend des dépendances réelles de la classe testée. S'il s'agit de classes simples que vous pouvez facilement instancier et configurer avec les données / états souhaités requis pour vos tests, vous n'avez besoin d'aucune simulation. (Cela semble être le cas pour votre exemple de conception ici.) Cependant, si l'une des dépendances est difficile à initialiser / a des dépendances étendues elle-même / a des effets secondaires indésirables / dépend d'une ressource externe telle qu'une base de données, alors cela a du sens pour utiliser un objet factice à la place.


Comme je l'ai déjà dit, c'était un scénario simple, juste pour en savoir plus sur les objets TDD et Mock ... Une excellente réponse, merci. Et qu'en est-il d'UML? Dois-je l'éviter?

@thomas, pas besoin d'éviter UML, il n'entre pas en conflit avec TDD. UML est très bon pour visualiser / communiquer les problèmes de conception. Cela peut être extrêmement utile à certains stades de développement. Cependant, la conception évolue, et essayer de garder un beau schéma de système UML synchronisé avec le code peut rapidement devenir un fardeau. Pensez donc à le jeter quand vous n'en avez plus besoin :-)
Péter Török

1
@thomas, btw la convention ici est de voter pour les réponses que vous trouvez utiles, en cliquant sur la flèche vers le haut à côté de la réponse :-)
Péter Török

4

Je ne vois pas beaucoup de besoin d'objets fictifs ici. Comme d'autres l'ont souligné, vous en avez besoin surtout si les dépendances sont difficiles à configurer.

Par exemple, nous les avons utilisés avec des projets Ruby on Rails lorsque nous avons testé des contrôleurs et avons eu besoin d'une connexion utilisateur qui aurait nécessité un appel à un autre contrôleur et le stockage d'une partie de ses informations dans un cookie. Dans ce cas, il est utile de se moquer d'un utilisateur connecté qui renvoie true, lorsqu'on lui demande un certain privilège d'accès.


2

Normalement, pour les tests, vous voulez isoler le système / objet testé, vous vous moquerez donc de tout ce qui est en dehors de cela. Donc, en utilisant votre diagramme de classes, lorsque vous testez un objet de commande, utilisez une maquette pour l'objet de ligne. Lors du test de la ligne, utilisez une maquette pour la commande et le produit. Lors du test du produit, utilisez une maquette pour Line.


Étant donné que le produit ne dépend pas de Line, il n'est pas nécessaire (ni moyen) d'utiliser une maquette pour Line là-bas. Idem pour la ligne et l'ordre.
Péter Török

2

"Le TDD est avant tout une technique de conception qui a pour effet secondaire de garantir que votre code source est soigneusement testé à l'unité" - Scott W. Ambler

L'idée est de trouver le design en écrivant des tests unitaires. Dans votre cas, il semble que vous ayez déjà le design en place, ce qui va un peu à l'encontre de l'objectif de TDD (en supposant que votre design est final).

Concernant la moquerie. Si vous voulez vous moquer, je vous suggère de vous moquer du produit lors de l'écriture des tests pour la ligne et de la ligne simulée lors du test de la commande. Mais c'est peut-être exagéré ici. J'essaie personnellement de limiter autant que possible les moqueries et de les utiliser pour découpler les dépendances des classes externes (telles que les instances de base de données).


2
J'ai juste un diagramme de classe simple ...

-1 Donc, penser à la conception (y compris griffonner un diagramme de classe) vous empêche de faire TDD? Cela semble tout simplement faux.
Bjarke Freund-Hansen,

1
@bjarkef: relisez ma réponse s'il vous plaît. Si la conception est définitive, vous ne pouvez pas vraiment utiliser TDD pour chasser la conception, c'est à cela que sert TDD. Et je pense que c'est aussi ce qui rend le PO confus: il a déjà une solution et essaie maintenant de lui écrire des tests. "Quels tests dois-je écrire en premier, Produit ou Commande". Cette question n'est pas vraiment pertinente si vous écrivez d'abord des tests.
Martin Wickman

Comment déterminez-vous que la conception est définitive sans aucun test ni code de production? En supposant que vous vouliez créer quelque chose qui fonctionne.
JeffO

@Jeff: Vous ne pouvez pas, évidemment. C'est une chose que TDD peut vous aider.
Martin Wickman du
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.