quels tests automatiser pour développer en agile?

bonjour,

je souhaite passer progressivement à une méthode de développement (sans doute scrum et XP ensemble).
Dans un premier temps, je désire améliorer nos pratiques d'ingéniérie logicielle tout en gardant notre méthode en cascade.
Mon premier sujet est l'automatisation des tests développeurs. Jusqu'au faut il automatiser les tests pour pouvoir passer en méthode agile? (automatiser seulement les tests unitaires? seulement sur la couche métier? automatiser les tests fonctionnels?...). Nous travaillons avec java.

Cordialement
loïc midy

Bonjour,

Avant toute réponse, n'oublie pas que l'Agilité prône "individuals and interaction over processes and tools". Les individus et les interaction valent plus que les processus et les outils. Ainsi, passer à une méthode type Scrum + quelques pratiques d'XP, c'est avant tout un changement de mentalités. Il n'y a pas de pré-requis pour passer à l'agilité, mais dans la recherche extrême d'efficacité les tests automatisés seront une évidence.

Ceci dit...
L'Agilité, quelque soit la méthode, va te demander d'augmenter drastiquement le nombre de releases. Par conséquent, tu auras besoin de gagner du temps sur la partie recette + debug. Et il te faut impérativement adresser les problèmes de régression. Ainsi, un travail important est d'automatiser les tests de recette.
Vu que tu travaille en Java, je suppose que tu fais du web. Regarde de prêt la solution Selenium IDE + Firefox. Ce petit soft permet à des non informaticiens d'automatiser des tests sur des site web. Lors d'une recette, met un développeur en binôme avec ta MOA. Lorsque l'ingé MOA effectue un test de recette, le développeur lui demandera de l'automatiser. Il sera là en support, uniquement s'il y a besoin de générer des valeurs aléatoires ou ce genre de chose plus "techniques".
Si tu en as la possibilité, regarde également comment fonctionnent les spécifications exécutables. Fit et Fitness sont les principaux que je connaisse dans ce domaine.

Voilà pour les tests de recette. Passons aux tests unitaires...
Trois objectifs pour les tests unitaires :
- Aucun temps de débug
- Non régression.
- Meilleur conception/architecture
Je passe sur l'aspect débug, car je le trouve évident. Si ce n'est pas le cas, n'hésite pas à poser des questions. Une fonction java bien couverte par des tests unitaires ne sera pas cassée par l'édition réalisée par un autre développeur. Cette fonction pourra être refactoré sans crainte. Par conséquent, en java, je prône le 80% de couverture du code. En effet, je ne trouve pas indispensable de couvrir les getters et les setters, ni les classes d'exception. Pour l'aspect conception, c'est moins évident à expliquer. Une fonction testable est un code qui a des entrées et des sorties identifiées, et qui ne mixte pas tout en interne. Après un peu de pratique, tu constateras que de tester systématiquement les fonctions permet de les rendre plus indépendantes les unes des autres. Cela oblige à ne pas tout mettre dans un gros "executeAction", sorte de "main" moderne.
Le principal problème auquel je suis confronté quand je propose de faire du test unitaire, c'est la formation des développeurs. En effet, bien que beaucoup connaissent l'existence de JUnit, très peu l'utilisent quotidiennement. XP proposant carrément de passer en Test Driven Developpement, un atelier ou même une formation dans ce sens est souvent indispensable.
Enfin, j'utilise énormément Mockito pour le test d'applications web. En effet, j'ai souvent à tester des objets difficilement instanciable, comme des HttpServletRequest, des webservices, des objets hibernate ou ce genre de choses.

Atteindre 80% peut sembler infaisable avec du code déjà existant. Je te conseillerais de lire "working effectivly with legacy code" si tu as un existant fort. Dans ce livre, tout code non testé unitairement est nommé legacy.

Enfin, si tu met en place cette architecture de tests unitaires, l'intégration continue est un outil formidable. Il s'agit d'un petit war, qui va a repasser les tests unitaires à chaque commit et envoyer un mail si l'application ne compile pas//contient une régression. Hudson fait ça très bien, et tu te rendras sans doute compte de la puissance de Maven si tu commence à l'utiliser. En cherchant un peu, on peut afficher tout un tas de statistique amusantes, comme la couverture de code, le nombre de problèmes remontés par findbugs, la taille du code, sa complexité, etc.

En conclusion, je dirais qu'il n'y a aucun "pré-requis" à l'adoption d'une méthode agile. Certaines équipes agiles reprennent et ajoutent des fonctionnalités à du code dit "legacy". Garde toujours à l'esprit quels sont tes objectifs en passant à ces méthodes.

Si tu as d'autres questions, n'hésite pas !

Cordialement,
Jonathan