Le document décrit la mise en place de tests dans un environnement hostile, en partant d'une situation avec peu de tests automatisés et une culture de développement archaïque. Il souligne les défis rencontrés lors de la réécriture d'un produit avec un nouveau framework, les efforts pour établir des tests unitaires, et l'importance de la formation et de la collaboration au sein des équipes. La conclusion met en avant que le succès des tests peut améliorer l'ensemble du développement, malgré les résistances initiales.

1. Une Mise en place de tests en
milieu « Hostile »
Mathieu Roger
CAST Software
http://www.agilbee.com/lab/
17/05/2012 1

2. Plan
• Situation de départ
• Les différentes étapes
• Situation d’arrivée
• Conclusions
17/05/2012 2

3. Situation de départ
• Niveau tests
– Une batterie de tests de ‘non régression’ coté
QA(testeurs)
• Coté code
– C++, grosse problématique de perfs et de stabilité
• Une culture ‘années 90’/’informatique propriétaire’
– Pas de tests ou très peu coté dev
• « les tests c’est le jeudi et à la main »
• Des précédentes tentatives de mise en place avortées
17/05/2012 3

4. La non-reg
• Récupérée du travail de la QA, assez classique
– Une hiérarchie de répertoires
• Un fichier d’entrée (ici du code source à analyser)
• Un fichier de description/paramétrage du test
• Une référence
17/05/2012 4

5. La non-reg
• Résultats
- 8H pour 600 tests, lancé sur les postes des devs la
nuit
- 10% de tests KOs ‘sticky’, phénomène de la
fenêtre cassée
- Pas vraiment Test Before car l’attendu n’est
généralement pas écrit avant
17/05/2012 5

6. Le début de la réécriture
• Réécriture du produit dans un nouveau
framework
– Le nouveau code était l’occasion de faire du TDD
– Malheureusement, le framework n’était pas prêt
• Demande mal reçue par l’équipe qui le gère
– « ne teste pas le ‘vrai’ produit »
– « ne résout pas ceci, cela… »
• Un lobying intense a résolu ce problème mais a
déclenché une guerre avec cette équipe
17/05/2012 6

7. 17/05/2012 7

8. • Le framework a été séparé de son adhérence
à la base de données
• Les tests sont restés dans le mode non-reg
– Uniquement des fichiers en entrée/sortie
– 2 secondes par test
– Grosse difficulté pour tester des traitements
intermédiaires
• La comparaison de fichiers contenant des données
intermédiaires est très complexe
17/05/2012 8

9. CPPUNIT (ouf! enfin!)
• Mon tour de réécrire sous le nouveau
framework
– Mon erreur était de n’avoir pas moi-même utilisé
le système de tests
• Objectif tests en CPPUnit
• Quelques demandes d’évolutions au framework
• Mise en place d’un Hudson bricolé sur ma machine
• Très rapidement contaminant : une équipe puis 2 etc..
• Formation externe TDD
17/05/2012 9

10. Du mieux
• Difficultés avec les utilisateurs
– « la couverture »
• Les test unitaires couverture + faible que de la non reg
• Mais infiniment plus stables
– « c’est compliqué de se mettre dans la situation
initiale »
• Montrer par l’exemple
• Avec l’habitude
– Les utilisateurs se sont copiés les uns les autres
17/05/2012 10

11. Du « encore » mieux
• Des mesures supplémentaires
– De couvertures de test
– De taille de code source
• fournit un « suivi » de la progression des équipes
• Des tests de charge/volume
– Permet de détecter les régressions de perfs
– De « prouver » les optimisations
17/05/2012 11

12. Exemple de mesures
17/05/2012 12

13. Exemple de mesures
17/05/2012 13

14. Exemple de mesures
17/05/2012 14

15. Fitnesse
17/05/2012 15

16. Exemple de test
17/05/2012 16

17. Conclusions
• Le manque/l’absence de tests traduit
– Un manque de connaissances  Il faut former/convaincre
– Une architecture bancale/complexe  le + dur
• La réussite est contagieuse
– Si le ‘produit test’ est bon le reste découlera tout seul
– Se focaliser sur des projets pilotes / Ne pas s’occuper des
réfractaires
• Une révolution
– Pas sans mal, Pas sans l’aide du managment
– Par « small steps »
17/05/2012 17