Tests unitaires et intégration continue

Je vais vous parler de deux notions qui sont assez connexes, et que certaines personnes ont tendance à mélanger un peu.

Les tests unitaires

Le but des tests unitaires est d’automatiser les tests de non-régression. Quand on développe un logiciel, on peut facilement faire des modifications sans se rendre compte qu’elles introduisent des bugs dans certains cas particuliers. C’est ce qu’on appelle des bugs de régression, en ce sens qu’on introduit de nouveaux bugs à la suite d’une évolution fonctionnelle. Comme il n’est pas humainement possible de tester systématiquement tous les cas d’utilisation possible, ces bugs peuvent se retrouver déployés en production, avec tous les problèmes que cela comporte.

Une des notions importantes, quand on fait du développement, est de savoir que plus un bug est détecté tôt, plus il sera facile à corriger. Les gros soucis arrivent quand on fait du « sur-développement » par-dessus un bug de régression ; il devient très difficile de faire un retour en arrière sur le code incriminé, car cela impliquerait de supprimer des fonctionnalités. Il faut alors corriger ce nouveau code, en essayant de trouver une aiguille dans une botte de foin.

Concrètement, les tests unitaires consistent en un ensemble de scripts, qui ont chacun en charge la validation d’un morceau de code (ou d’une classe si vous faite de la programmation orientée objet). Il est assez évident de tester de la sorte les bibliothèques de fonction : les « librairies » peuvent être vues comme des boîtes noires, avec des entrées et des sorties. Il suffit d’injecter certaines données en entrée, et vérifier la conformité de ce qu’on obtient en sortie.
Pour du code applicatif, c’est un peu plus délicat, car on est parfois obligé de mettre en place un environnement de test sophistiqué (bases de données avec lots de test, génération de données aléatoires, gestion des tentatives de hack, …). Mais bien heureusement il existe de très nombreux frameworks pour vous aider à y arriver ; suivant votre plate-forme de développement, vous pouvez vous intéresser à JUnit (Java), SimpleTest (PHP), CppUnit (C++), JSUnit (Javascript), ASUnit (ActionScript), Test::Unit (Ruby), Test::Unit (Perl), unittest (Python), NUnit (.NET), …

Choisir ou être choisi

Quand on a un poste de manager, que l’on doit gérer des personnes, il y a une notion qui peut parfois faire une grande différence : avoir été choisi pour occuper ce poste, ou choisir les personnes que l’on aura à gérer.

Choisir

C’est l’option la plus confortable. Vous arrivez au tout début d’un projet, à la création d’un service ou d’une entreprise. Saisissez cette grande opportunité ! Vous allez pouvoir faire les choses à votre manière.

Recrutement

Votre équipe est vide, il va falloir la constituer. Vous allez pouvoir choisir les personnes qui vont vous rejoindre. Même si je ne vais pas m’étendre sur le sujet pour le moment (il est trop vaste), il n’en reste pas moins que c’est le meilleur moyen d’entamer une collaboration. Vous allez choisir ces personnes ; dès l’embauche vous aurez commencé à tisser des liens privilégiés. Cela ne garantit pas le succès d’une collaboration, mais ça peut grandement la faciliter.

Méthodes de travail

Vous pouvez mettre en place les méthodes que vous voulez, soit parce que vous les avez déjà rodées, soit parce qu’elles vous semblent pertinentes. N’ayez pas peur ! Ce ne sont pas vos supérieurs qui s’y opposeront : ils seront très heureux de s’en remettre à vous, et plus vous montrerez votre dynamisme à ce niveau, plus ils vous feront confiance.