Il est temps de retourner voir notre ami Alex et sa régie, avec une nouvelle problématique rencontrée par les projets : les tests !

Ce projet est d’ailleurs très vigillant sur ce point, et la dernière évolution technique a été l’occasion de faire une refonte et un passage sur l’intégralité des tests du projet ! Est-ce que cela a eu un impact sur le moral des développeurs de réécrire et maintenir tous les tests JUnit ? Que neni ! Et pour cause, il n’y en a pas !

Le problème

Tous les tests sont enregistrés sous TestDirector et sont… manuels ! Toute l’équipe a donc été mobilisée pour vérifier, réécrire et repasser un bon millier d’entrées sous TD, soit un historique de 3 ans. Un travail passionnant qui aura marqué les esprits, mais surtout nécessaire car c’est uniquement sur la base de ces rapports de tests manuels que les commandes des lots sont validées.
Consommer la productivité de 15 personnes pendant 1 mois est-il le prix à payer pour la « qualité»  ?

Pourtant la notion de tests unitaires n’est pas inconnue de l’équipe. Ceux ci existent sous deux formes :

  • Pour les gens de Java c’est un abus de language et désigne en fait des tests IHM de surface ou des tests d’intégration assez simplistes. Parlons nous de la même chose ?
  • Pour les gens de Pacbase se sont de vrais tests unitaires type boite blanche… cependant impossible de conserver un reférentiel des tests quelque part et de tout repasser d’un coup. Il faut réécrire et repasser le test à chaque fois ! Que devient la non régression ?

Cependant les gens de Pacbase ont le mérite de faire de vrais tests, et ne manquent pas de faire remarquer aux Java(wo)men qu’ils sont rigoureux, eux, pour le plus grand agacement d’Alex et Fred.
Mais le framework J2EE maison utilisé sur le projet n’a pas vraiment été pensé pour les tests… écrire du code JUnit relève de la prouesse (encore faut-il essayer !) et un harnais de log de debug remplace le harnais de tests automatisés. Comment dit-on déjà ? Mieux vaut prévenir que guérir ?

Effectivement dans ces conditions les anomalies sont difficiles à détecter, à corriger (comment être sûr sans véritables tests ? Est ce que je ne casse pas autre chose ?), et surtout elles sont nombreuses !

La solution

Alex est chargé de coder une partie de la couche logique en Java ! Jour de fête car on en parle depuis 6 mois et la chose est traditionnellement codée en Pacbase. La réalisation est plus rapide que les délais prévus (un accident, ça arrive !) et Alex se sentant en mesure de redorer un peu l’image de Java auprès des anciens décide d’aller plus loin.

Disposant d’un peu de temps devant lui et d’un framework (maison) différent de celui de d’habitude, il choisit donc de coder quelques tests avec JUnit. Bonne nouvelle, c’est possible ! Et comme ça marche plutôt bien, il fait en sorte de généraliser un peu son travail pour fabriquer un mini-framework de tests automatisés. Grande première ! Alex est content de son idée, c’était plus intéressant que de coder des get() et des set() et surtout c’est profitable au projet.

Alex envoi donc son travail testé en recettes et aucune anomalie n’est remontée sur la couche logique ! Même en cas de doute, les erreurs sont immédiatement identifiées comme dépendantes des projets connexes grâce au passage rapide de la batterie de tests automatisés.

Avec l’économie du temps dédié à la correction des anomalies, Alex décide de pousser plus loin son framework de tests. Après quelques heures, toute la partie Pacbase peut désormais être testée automatiquement ! L’écriture des cas de tests n’est pas compliquée et consiste généralement à copier-coller un peu de xml dans un fichier. Plusieurs personnes se mettent à l’utiliser, même Sénéchal (un Pacbasien) qui ne connait rien à Java / Eclipse / JUnit (un petit tutorial sur le wiki pour l’aider ?).
L’outils permet maintenant de construire un harnais de tests pour la non régression et le diagnostic des erreurs est grandement accéléré. En effet, il n’est plus nécessaire de faire des déductions à partir des logs de debug maintenant que l’on dispose immédiatement des résultats exacts des appels.

Avec encore un peu d’efforts, Alex arrive à étendre son outils pour tester de façon automatisée la couche navigation, intestable jusqu’alors… de nouvelles possibilités s’ouvrent au projet.

Encore un problème ?

Et oui ! Alex n’a pas la même vision du travail terminé que certains de ses chefs de projets… Le développement peut apparement être considéré terminé, même sans être testé ? Alex a pris une initiative et se fait réprimander pour cela, il aurait du faire d’autres développement au lieu de tester les siens. Les tests préjudiciables à la réussite du projet ?

Enfin, ces tests automatisés maintenant qu’ils sont là on devrait pouvoir les exploiter ? Oui, si l’on veut… Alex est toujours obligé de remplir ses « tests unitaires»  sous Test Director et de les passer manuellement, comme tout le monde… les tests automatisés sortant du cadre définit il y a 3 ans pour le projet ils ne sont pas considérés comme valables pour établir les cahiers de tests… Cycle en V, procédure… ou comment contribuer au succès du projet ?