Le test unitaire automatisé (en utilisant un framework de type XUnit le plus souvent) est un sujet à la mode. Tester automatiquement est de plus en plus souvent envisagé sur les projets informatique. Mais ceux qui s’essaient à l’exercice découvrent rapidement que les questions sous-jacentes à sa mise en oeuvre abondent : qu’est-ce qui mérite d’être testé ? Qu’est-ce qui est testable ? Quand estce que l’on a suffisamment testé ? Qui va écrire les tests ? Qu’est-ce qu’un bon test ?

Trop d’équipes se lancent dans l’aventure sans une vision précise sur le rôle du test unitaire automatisé. Elles en espèrent, de façon assez abstraite souvent, un gain en qualité et en robustesse. Elles espèrent un déploiement de l’application sans drame et une maintenance facilitée. Ces équipes constatent, après quelques semaines ou mois d’efforts, que ces espérances restent aléatoires. Arrive alors la tentation : abandonner le test unitaire automatisé au nom du réalisme et des contraintes diverses du projet (moyens, délais).