"Non mais nous, on ne peut pas tester" Vous avez déjà entendu cette phrase ? Parce que moi, oui, très souvent. Il y a toujours au moins une bonne raison évoquée. Et si on en parlait ?

1. POURQUOIVOUS NE POUVEZ PAS TESTER VOTRE
CODE

2. RÉMI LESIEUR
• Coach
– Software Craftsmanship
– DevOps
– Agile
• DevOps
• Dev FullStack (mais plutôt back)

3. PETITE HISTOIRE
Nous on a une architecture compliquée avec 8 bases de données synchronisées et 15 web services
parallèles qui appellent 50 APIs concurrentes pour lancer un workflow écrit en FORTRAN par un stagiaire en
92 …
On ne peut pas implémenter aussi facilement des tests.

4. LES STANDARDS INSISTENT SUR LES TESTS DU CODE
• Un Standard ?
– La meilleure façon identifiée de réaliser une action
• Continuous Testing
– eXtreme Programming
– DevOps

5. ON A UNE ARCHITECTURE TROP COMPLEXE
• Nous, on a une base de données !
• Et puis des fichiers !
• Sur un partage réseau !
• Et on s’interface avec d’autres systèmes / progiciels !
 Vous avez pensé aux doublures de tests (Ou mocks) ?
 Mockito en Java
 Moq en .Net
 Revoir l’architecture du produit

6. C’EST TROP DE BOULOT / CA COÛTE TROP CHER / ON N’A PAS LE TEMPS
• On doit livrer les features au client, c’est plus important
• Le client ne voudra jamais payer pour ça
 Quel est votre temps passé à corriger des bugs ?
 Ca coûte combien une phase de recette chez vous ?
 Mettez en lumière le temps passé à maintenir le code existant vs les nouvelles features.
 Définissez un plan de reprise de la dette technique.

7. ON NE VOIT PAS L’INTÉRÊT
• On a déjà la Q.A. (Quality Insurance / Assurance Qualité) qui teste
• Si on fait ça, la Q.A. va râler parce qu’on prend son boulot
 Est-ce le boulot de la Q.A. de s’assurer que l’application soit stable ?
 Est-ce qu’elle vérifie systématiquement toutes les features avant livraison ?
 Ce n’est pas un peu redondant ?
 Tester “à priori” de la QA, c’est faciliter son travail
 Elle cherche elle-même à automatiser ses tests
 Les intégrer dans la réflexion ? Cf. Cucumber, FitNesse, …

8. ON NE VOIT PAS L’INTÉRÊT (V2)
• On n’est pas payés pour tester
• Je m’en fous c’est pas mon code
 Retour à la question sur le temps passé sur les bugfix et les phases de recette
 Vous pensez aux évolutions d’architecture ?
 Se référer au cadre (XP, cycle en V) choisi par l’équipe, il y a sûrement une phase dédiée aux tests
 Si vous n’en n’avez pas, il serait intéressant de s’y pencher
 Si le cadre n’en parle pas, peut-être êtes vous trop haut niveau (organisationnel type Kanban)

9. TESTER SON CODE, CE N’EST PAS MAGIQUE
• Temps
• Investissement
• Parfois ralentir / limiter les features pour privilégier le refactor
• Investissement à long terme
– Entretient / révision
– Le « risque de ne pas faire » est souvent invisible
• Nombre de bugfix / hotfix
• Temps de MEP
• TTM
• Ne pas forcer l’équipe, les amener à comprendre pourquoi c’est important et ce qu’ils y gagnent
• Ne pas les laisser seuls (katas, formation, coaching)
– Risque de laisser l’équipe dériver