XXP

mai 2016

lun. mar. mer. jeu. ven. sam. dim.
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31          

« Peur sur les tests unitaires | Accueil | Peur sur les tests unitaires »

20 juin 2008

Peur sur les tests unitaires

Une note de Sami Jaber qui pointe un billet de Oren Eini (Ayende Rahien) jette le doute (le Web dit "FUD" : Fear, Uncertainty and Doubt) sur la pratique des tests unitaires : "Pour tester une classe contenant 4 champs et une méthode, [Ayende] code une classe de test quasiment 10 fois plus importante [que la classe à tester] et contenant une dizaine de méthodes. Tout cela fait réfléchir sur les coûts des tests unitaires. A ne pas négliger."

Vu l'inertie voire la résistance des informaticiens français face aux méthodes agiles de développement de logiciels, qui s'appuient souvent en grande partie sur les tests unitaires, personne n'avait besoin d'entendre une rumeur de type "10j de tests unitaires pour un jour de fonctionnalité".

Ce qui me gène, c'est que ce rapport de 10/1 est tout simplement faux. J'en parle en connaissance de cause puisque je ne développe plus sans tests unitaires depuis quelques années (sauf petits logiciels "kleenex").

A la décharge de Sami, le billet d'Ayende Rayen, avec tout le respect que m'inpire sincérement son auteur, prête à confusion. Néanmoins les points suivants auraient pu attirer son attention : 

  • L'initialisation de la couche de persistance apparait dans les tests unitaires (TestFixtureSetup et Setup), pas dans l'implémentation de la classe à tester. Pour comparer équitablement, il faut ajouter cette initialisation à l'implémentation, soit 13 lignes qui viennent alourdir l'implémentation.
  • Dans les tests unitaires, l'initialisation de la couche de persistance est généralement écrite une seule fois et partagée à un grand nombre de tests unitaires. Le coût fixe du code à écrire pour cette initialisation est donc dilué par le nombre de tests. Une lecture trop rapide de la classe de tests d'Ayende sous estime le code partagé.
  • A l'inverse de ce qui est annoncé par Ayende, la classe WebcastRepositoryTest ne teste pas unitairement WebcastRepository. Elle teste aussi la couche de persistance via les tests Can_save_webcast() et Can_load_webcast(). Ces fonctionnalités de load/save doivent être garanti par un autre ensemble de méthodes qui testent unitairement la persistance, précisément la propriété Inner de typeIRepository<>. Pour s'en tenir aux tests de WebcastRepository il faut supprimer ces deux tests de persistance, soit 21  lignes d'allègement.
  • Les méthodes dont le nom suggère la simplicité peuvent être de vrais casse-têtes. Imaginez les tests pour la méthode Think(). Dans l'exemple de Ayende, GetLatest() devrait s'appeler GetLatestPublishedWebCast, et mérite bien 4 tests.
  • Linq  offre une grande concision d'écriture qui ne doit pas laisser croire qu'il ne reste rien à tester.

Que les tests aient un coût, certes, mais certainement pas dans un rapport 10/1. Et ils rapportent d'autant plus gros  que le logiciel est amené à évoluer. S'ils le savaient, les clients des SSII devraient exiger des tests unitaires à tous les étages.

Sources :

DotNetGuru : Le coût des tests unitaires

Ayende Rahien : Answer: How many tests?

TrackBack

URL TrackBack de cette note:
https://www.typepad.com/services/trackback/6a00d8341c871f53ef00e5535f5f1a8833

Listed below are links to weblogs that reference Peur sur les tests unitaires:

Commentaires

L'utilisation des commentaires est désactivée pour cette note.