Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Mise En Place De Tests En Milieu Hostile (C++, CppUnit) - 25 mai 2012

1,068 views

Published on

Published in: Education
  • Be the first to comment

  • Be the first to like this

Mise En Place De Tests En Milieu Hostile (C++, CppUnit) - 25 mai 2012

  1. 1. Une Mise en place de tests en milieu « Hostile » Mathieu Roger CAST Software http://www.agilbee.com/lab/ 17/05/2012 1
  2. 2. Plan • Situation de départ • Les différentes étapes • Situation d’arrivée • Conclusions 17/05/2012 2
  3. 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. 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. 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. 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. 7. 17/05/2012 7
  8. 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. 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. 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. 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. 12. Exemple de mesures 17/05/2012 12
  13. 13. Exemple de mesures 17/05/2012 13
  14. 14. Exemple de mesures 17/05/2012 14
  15. 15. Fitnesse 17/05/2012 15
  16. 16. Exemple de test 17/05/2012 16
  17. 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

×