IMG_4333“No more Excuses” : C’est par ces mots que Luis Majano (Ortus Solutions – Président) entame sa présentation des outils de tests unitaires comme un leitmotiv pour promouvoir la vertu des tests unitaires et surtout de les automatiser.

Plus excuses car maintenant on le sait, trop d’applications sont livrées “en mode debug” c’est laissant finalement le soin aux utilisateurs de réaliser une partie (et parfois importante) des tests unitaires avant de se pencher sur les tests de qualification qui devrait finalement être leur priorités.

Bon ça c’est le raccourci et on pourrait penser que l’implémentation des outils résoudrait tous les problèmes facilement.

En réalité, Luis nous dresse le panorama d’outils relativement complexes à implémenter surtout sur des applications existantes qui n’ont pas été forcément pensées “Tests Unitaires” dès leur conception. Ce qui est le cas de nombreux projets qui ont subit année après année des modifications fonctionnelles, parfois majeures. Luis nous expose même un risque qui reviendrait à tout simplement pas y arriver.

Le conseil est donc de bien évaluer ce que l’on veut privilégier au niveau des tests unitaires. De même, la définition même des tests unitaires est soumise à interprétation. Pour ce qui nous est présenté aujourd’hui il s’agit d’avantage de  tests de conformité “technique” du code : respect des syntaxes, des conventions, des typages, des retours de fonctions… Bref, pas vraiment des tests fonctionnels basiques qui sont finalement classés dans les tests fonctionnels.

Selon l’atelier que nous avons suivi ce matin, j’ai noté que les tests unitaires visaient surtout à livrer une application qui ne bogue du point de vue syntaxique et pas forcément qui donne un traitement juste.

IMG_4334

Dans l’atelier ColdFusion Craftsmanship, Kev McKabe introduit d’ailleurs le concept de test (Test Driven Development) et de comportement (Behaviour Driven Development). Cela signifie que les clients qui souhaiterait automatiser les tests unitaires pourraient être déçus du résultat car ils ne couvrirait que des aspects très techniques du code.

Luis nous dresse ensuite une liste d’outils qui, se cumulant les uns aux autres, forment une chaîne de production du code (“principe de software factory”).

Deux outils open source sont particulièrement cités :

Les démos sont assez saisissantes et convaincantes. En quelques secondes, des milliers de lignes de codes sont automatiquement récupérées du repositiry (SVN, Git, CVS, etc.), passée au crible et un build sort une application prête à tester. Si une erreur apparaît, le code n’est pas réputé valide. Dans certaine condition de paramétrage, on peut même lancer ces tests au moment du “submit” évitant de pousser sur un repository un code erroné. Du coup, en tant que développeur, on comprend bien l’avantage d’intégrer très tôt dans la conception logicielle ces outils et méthodes.

Cependant, Travis semble avoir un intérêt particulier avec l’utilisation de Coldfusion car il intègre un moteur supportant les dernières versions et y compris sa version open source Lucee.

En conclusion, si l’automatisation des tests dans le principe de Continious Integration, Coutinious Delivery est un point de passage obligé dans l’implémentation moderne d’une production logicielle ne constitue pas pour autant une solution magique et simple à mettre en place.

 

 

 

Leave reply

Send us feedback!


Your email address will not be published.

 Last News