Je suis moi aussi gêné par la définition de Feathers.
Un test qui utiliserait 50 classes de mon application, mais pas la BD, pas de fichiers, pas le réseau et pourrait s’exécuter en même temps qu’un autre, rempli les critères de cette définition.

Je comprends son intérêt didactique, et plus particulièrement dans un environnement legacy (code existant sans tests). En effet, sans environnement maitrisé, tester n’est pas possible (unitairement ou pas d’ailleurs) car je ne suis pas sur que mon test aura le même comportement d’une exécution sur l’autre.

Cependant, j’ai tendance à considérer que le granularité de mon test doit être fine (i.e. il ne doit tester si possible qu’une méthode, dont les dépendances sont mockées, donc maitrisées) car :
1. Si je veux tester la combinatoire d’un test impliquant 50 classes, il ne me faudra pas moins de test – je ne gagne rien à impliquer 50 classes si ce n’est l’effort de mock (pas négligeable parfois je l’accorde)
2. Je vois les tests comme un outil pour trouver une erreur, et j’ai envie que les lumières rouges m’indiquent le plus précisément possible ou se trouve mon erreur / la régression.
3. Je documenterai plus précisément mon application (les tests unitaires sont écrits pas les développeurs, pour les développeurs).

Nous sommes d’accord sur le fait qu’il faut bien commencer par un bout, et que la définition de Feathers m’aide à cela (elle indique le bon bout pour commencer). Je vois donc cette définition plus comme un outil que comme un dogme (comme Mathieu je pense).

Nous sommes d’accord également que je pars du principe que la classe String du framework .NET fait ce qui est marqué dans sa documentation (le framework est livré sans ses tests ;-)) et que mon TestRunner ne m’affiche pas une lumière verte lors d’une assertion non vérifiée ;-)

Merci Mathieu pour cet article et merci Romain tes précisions.
Vive les moyens de communication chauds et le code (au 18 mars ?!?).

Le ton de ta réponse me laisse penser que tu as pris mes remarques personnellement :) Ca me désole un peu car il ne me semble pas avoir émit un jugement te concernant, ou concernant tes méthodes de travail.

Ton collègue Djamel Zouaoui, d’Octo, participera à la réunion ALT.NET parisienne du 18 mars pour animer une présentation sur le TDD. Même s’il s’agit de .NET, je t’invite à venir y faire un tour. Nous pourrions ainsi échanger nos points de vue de vive voix, et il est très probable que je parvienne à mieux me faire comprendre ainsi.

Nous sommes apparemment déjà d’accord sur le fait que le testing est une discipline nécessitant une grande pratique. C’est encourageant, non ?

A bientôt j’espère.

>> tu as besoin d’une instance de Bar, qui a elle-même besoin d’une instance de >>FooBar. Il est donc impossible de tester Foo en complète isolation

J’espère que tu isoles ton code pour mocker les classes String, Integer, etc car tu vas en avoir besoin pour être en totale isolation.

Puis

>>Attention, je ne suis pas un malade mental qui pense que toutes les classes >>doivent pouvoir être testées en isolation :) Il peut arriver que l’on décide de ne >>tester que la racine d’un aggrégat lorsque l’encapsulation a du sens.

Ca dépend, dans le découpage Commande / Service / Repository, tu dois pouvoir tester unitairement, avec des mocks ou pas. Dans le cas du repository, tu auras le choix, comme dans mon article, entre des tests d’intégration ou unitaire.

>>Je cherche juste dire que ce qui ressemble à un test unitaire n’est pas forcément >>un test unitaire.

Et la pureté n’existe que dans les laboratoire. Je pense que pour développer et tester, on a besoin de quelques règles simples (j’en expose quelques unes dans l’article, il y en a plein d’autres) et beaucoup, beaucoup de pratiques. Et j’ai souvent utilisé la définition de Feathers lors de mission sur des projets agiles, elle a souvent été bien accepté par les développeurs, et permettait de clarifier de nombreuses choses dans des tests qui commencent à devenir compliquer.

Bref, je pense que l’on parle de cas particulier, qui nécessite d’être tranchés devant du vrai code, dans un IDE, avec un clavier …

Mais quel composant la méthode « I_can_haz_cheezburger » teste unitairement ?

Si le teste échoue, est-ce que le problème vient de Foo ? De Bar ? Ou de FooBar ?

Ici le setup est trivial, mais il n’est pas difficile d’imaginer un graphe de dépendances plus complexe, et des types plus complexes. Sans découplage, la granularité du test est compromise, et peut empêcher ce dernier d’être pertinent.

D’où la nécessité d’un design permettant les tests unitaires, d’où la nécessité d’utiliser des abstractions afin de pouvoir stubber/mocker les dépendances. L’exemple posté est une illustration de ce problème : le design ne permet pas de profiter pleinement de l’intérêt des tests unitaires, puisque pour tester une instance de Foo, tu as besoin d’une instance de Bar, qui a elle-même besoin d’une instance de FooBar. Il est donc impossible de tester Foo en complète isolation. Tu es obligé de tester Foo avec Bar avec FooBar. On est déjà dans quelque chose qui ressemble à un roundtrip, puisqu’on ne teste en réalité qu’un agglomérat de composants, et non pas chaque composant unitairement.

Attention, je ne suis pas un malade mental qui pense que toutes les classes doivent pouvoir être testées en isolation :) Il peut arriver que l’on décide de ne tester que la racine d’un aggrégat lorsque l’encapsulation a du sens. Ici, pour que ça soit plus clair, on peut imaginer que Foo est un controller, que Bar est un service, et que FooBar est un repository. Et dans ce cas, il est évident que pour tester un controller en isolation, je ne veux dépendre d’aucune implémentation concrète de service. De même, si Foo est une vue, Bar un presenter, et FooBar une commande (quel exemple !), on ne peut pas prétendre tester la vue unitairement en gardant un couplage si fort inter-implémentations.

Je cherche juste dire que ce qui ressemble à un test unitaire n’est pas forcément un test unitaire. Et encore une fois, le fait d’être détaché d’une base de données (ou d’une autre dépendance évidente assimilable) ne garantit en rien le caractère unitaire d’un test. Certains designs laissent d’autres dépendances moins visibles compromettre l’atomicité des tests et réduire (voire même annuler) leur intérêt.

Désolé, c’est du C#.

Sur la question de la pratique du développement piloté par les tests, elle est évidement essentielle.

Pour ma gouverne, j’aimerais avoir un exemple parmi les 1001 façons de respecter la définition de M.Featers, sans que ce soit un test unitaire (et je ne parle pas encore de TDD).

Thomas : En terme de bonnes pratiques, j’ai pu voir des confs de tests, identique à celle qui part en prod, mais avec tout l’environnement externe bouchonné (BDD en mémoire, …). Dans d’autres cas, c’était une configuration dédiée au test, mais évidement éloignée de celle qui part en prod. Et dans d’autre un peu des deux. Et il faudrait que je vois un bout de ton code pour donner un avis plus tranché :)

Pour la question des mocks, il y a en effet un tradeoff sur la réécriture du code de dépendance. Si tu réécris beaucoup de code pour préparer tes mocks, afin de tester, c’est aussi une info sur l’état de ton code …

Je disais précédemment que tester est compliqué, en voici une des raisons. Il y a des dizaines de questions de ce genre à se poser, et les concepts manipulés sont loin d’être triviaux.

Quelques pointeurs, toujours au sujet de « interaction-based tests versus state-based tests » :

Martin Fowler, qui explique bien les différences essentielles qu’il faut faire entre les différents types de test-doubles :

martinfowler.com/articles…

Un article de Ben Pryor sur toute la question :

benpryor.com/blog/2007/01…

Un post de Jeremy D. Miller, auteur de StructureMap dans le monde .NET :

codebetter.com/blogs/jere…

Mes deux centimes au sujet des tests unitaires : la définition qui en est proposée me laisse un peu mal à l’aise… Il y a 1001 façons d’écrire un test qui respecte les 5 critères listés sans pour autant que ce dernier soit unitaire. Si on considère un vrai système – et non pas l’exemple bateau consistant à tester un ICalculator – écrire un test unitaire pertinent est souvent une tâche dont la complexité est sous-estimée. A mon sens, la seule façon d’y parvenir est de pratiquer massivement, et surtout, d’en comprendre profondément l’intérêt. Les commandements de M. Feathers sont à considérer comme la description de quelques conséquences évidentes de l’isolation. Mais les contre-exemples sont trop nombreux (1001) pour qu’on parle de définition.

Suivre quelques guidelines, se baser aveuglément sur les rapports de coverage, ou le nombre de tests est selon moi le meilleur moyen de s’égarer. Il n’y a pas de balle-en-argent, hein.

Programmer c’est compliqué, tester c’est compliqué, donc let’s go shopping !