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