Test unitaire ? Mock ? TDD ? Kezako ? (En finir avec les régressions) – Atelier Paris Web 2013

Cet article fait partie de la série sur les ateliers Paris Web 2013.

Cet atelier était présenté par David Wursteisen (@dwursteisen).

Le test est ici mis en avant comme, entre autres, un « garde-fou » lors de la modification d’un code. L’exemple le plus parlant est la reprise d’un code pré-existant : on se retrouve parfois à se perdre dans une structure hasardeuse voire désorganisée pour modifier le petit bout de fonctionnalité souhaité, en priant très fort pour que ca n’ait pas d’ »effets indésirables » sur d’autres morceaux de l’application… L’absence de documentation/commentaires, et l’impossibilité de communiquer avec les créateurs initiaux rendent alors l’exercice périlleux.
Le processus de fonctionnement indiqué est le suivant :
– écriture de tests
– modification du code
– lancement de l’application et exécution des fonctionnalités
– vérification des résultats de tests
– si pas OK, on reprend le cycle à la modification du code.

Cette base posée, on rentre alors assez vite dans l’exercice : refactoriser et compléter le code d’une petite application javascript, en se servant de QUnit pour tester.
Cela permet de voir la mise en place rapide de tests simples : QUnit permet de comparer les valeurs retournées après action avec les valeurs attendues, et met en évidence les différences de résultat.
Tout ceci est bien complété par Blanket.js, qui indique le « taux de couverture » du code : il surligne les parties du code qui ne sont pas couvertes par les tests écrits.
Attention, une couverture à 100% ne veut pas dire qu’on peut être sûr à 100% que nos tests recouvrent tous les cas de figure, mais cela donne déjà une très bonne base. L’idée est donc de mettre en place au départ une série de tests qui couvre le maximum du code.
Après chaque modification, la couverture du test peut baisser : cela peut vouloir dire que le code non-couvert est maintenant inutile, mais aussi que ce cas n’est plus couvert par le test… Il faut donc jauger prudemment les indications.

Mon impression globale de cet atelier est une petite déception, car je m’attendais au moins à une explication détaillée des termes du titre, et j’avais imaginé qu’on rentrerait plus dans le processus d’écriture de tests.
Au final, on a surtout travaillé sur le refactoring de code, sans s’appesantir sur pourquoi on avait choisi de mettre en place ces tests-là en particulier, ou étudier les différentes possiblités à ce sujet.
Ca a été néanmoins une bonne petite introduction aux tests javascripts, et donne l’impression que c’est surtout destiné aux applications « lourdes » en interactions et manipulations de données. Un équivalent PHP serait donc probablement le plus indiqué dans notre cas.

A lire aussi :

Première participation aux ateliers Paris Web

Et si on enrichissait nos frameworks CSS ?

Rendre son application HTML5 accessible en 4 étapes

Projets responsive : mise en commun de retours d’expérience

Retourner sur la liste des articles