En présentant les tests fonctionnels automatisés chez un client la semaine dernière, plusieurs questions ont été soulevées. La principale était celle-ci:
- Pourquoi écrire ces tests FitNesse/GreenPepper alors que j'ai déjà des tests unitaires JUnit qui couvrent la même fonctionnalité ?
La question est justifiée. Voici quelques éléments de réponse, tirés de nos échanges sur les mailing-lists OCTO...
Tout d'abord, parce que les tests unitaires et les tests fonctionnels sont écrits par des personnes différentes.
Les tests unitaires sont écrit et utilisés par les développeurs. Ils sont codés dans le même langage que l'application testée, leur exécution est rapide, ils sont régulièrement refactorés, modularisés, etc. Ils sont non négociables (!) et doivent tester l'intégralité du code applicatif.
Mais ces tests unitaires ne sont pas appréhendables par les fonctionnels (client, MOA, AMOA, etc.)
Et c'est là qu'interviennent les tests fonctionnels automatisés: ils sont écrits par les fonctionnels et sont "lisibles par un humain".
Finalement, "s'il y a des doublons, c'est une coïncidence, en quelque sorte :)".
Idée 1: On rencontre sur beaucoup de projet des tests "boite noire" développés avec JUnit: ce sont les tests d'intégration. Ils passent par plusieurs services, DAOs, par la base de données, etc. Ces tests sont utiles car ils permettent de tester la communication entre les couches, la configuration, etc. Mais ils sont généralement lents à exécuter. Il faut donc les utiliser avec précaution ! Deux raisons possibles à l'utilisation massive de ces tests d'intégration: ou bien le projet ne dispose pas d'outils dédiés aux tests "boite noire" (FitNesse, GreenPepper, Selenium, etc.), ou bien ceci est dû à une méconnaissance des outils de Mock et des pratiques associées. Quelle qu'en soit la cause, limiter le nombre de ces tests "d'intégration" au profit de tests plus "unitaires" permet de réduire considérablement la durée globale d'exécution des tests. Et avoir des tests rapides, cela permet de les exécuter souvent, et donc de détecter les anomalies plus tôt.
Idée 2: Séparer les tests unitaires (rapides) des tests d'intégration (lents) est une bonne pratique. Ceci peut se faire par convention de nommage des classes de test, répertoires séparés, annotations ou autre. Une fois les tests JUnit catégorisés, des outils comme Maven permettent de définir des règles du type "les tests unitaires se lancent sur le poste développeur, les tests d'intégration s'exécutent uniquement sur le serveur d'intégration continue". Cette séparation permet d'éviter le travers (récurrent) suivant: "les tests sont trop longs, je ne les exécute pas localement et les délègue à l'intégration continue".
Enfin, et c'est le point le plus important, les tests unitaires et les tests fonctionnels automatisés poursuivent des objectifs complémentaires:
Nos projets intègrent plusieurs types de tests. Parmi eux, les tests unitaires et les tests fonctionnels couvrent les mêmes fonctionnalités, il est donc normal d'avoir le sentiment qu'ils se recoupent parfois.
Cependant, ils sont écrits par des personnes différentes, avec des niveaux de granularité différents et, surtout, des objectifs complémentaires: - Faire bien le produit, pour les uns - Faire le bon produit, pour les autres
En revanche, c'est au niveau des tests unitaires ou d'intégration qu'il est important de commencer la chasse aux doublons ! La durée de votre build ne s'en portera que mieux!
Un grand merci à Ismaël Héry, Julien Jakubowski, Eric Pantera, Arnaud Huon, Rémy-Christophe Schermesser, Christophe Thibault, Henri Tremblay, Maria-Dolores Manzanedo, Sylvain Fagnent, Bertrand Paquet, Sylvain Mazaleyrat et Florian Marin pour ces échanges et retours d'expérience enrichissants !