Faites des tests - Djangocong 2013

Quel est le seul outil qu'un forgeron de l'extrême ne puisse se passer ? Les tests pardis !

Transcript

1. Forgeron de l’extrême FELD Boris - Djangocong 2013
2. /me FELD Boris - Développeur Informatique Évangeliste Python et Open-Source Mon quatuor gagnant: Python/ØMQ/MongoDB/Tornado @lothiraldan un peu partout sur le web
3. Un job dont vous êtes le héros
4. Disclaimer Tous les personnages de cette histoire, même basés sur des personnes réelles, sont entièrement fictionnelles. Toute ressemblance serait parfaitement fortuite.
5. Vous êtes : Un stagiaire Une nouvelle recrue Un vrai développeur Un boulanger reconverti
6. Votre boss vous appelle dans son bureau
7. Vous devez : Créer un nouveau projet Ajouter de nouvelles fonctionnalités à un projet Réecrire un projet Copier un projet d’un concurrent Rejoindre un projet déjà en retard
8. Vous commencez à coder
9. Un problème : Vous demandez à votre voisin Vous demandez à google Vous demandez à stack overflow
10. Ça avance bien (tant mieux pour vous !)
11. Mais vous vous souciez de la qualité
12. Vous décidez d’écrire des tests, mais Il n’y en avait pas sur l’ancien projet Vous n’avez pas le temps Votre boss vous dit que vous n’avez pas le temps Vous faîtes de l’agilité, ya pas besoin Les tests c’est pour ceux qui savent pas coder Les tests ça sert à rien
14. Vous ne vous en rendez pas encore compte, mais vous venez d’être maudit
15. Donc vous ne faîtes pas de tests...
16. Et voici la mise en prod : Il y a tellement de bugs que c’est inutilisable Vous n’avez pas réussi à mettre en prod Vous avez détruit la base de données de prod Tout se passe bien (21 avec 2D10)
17. Vous essayez tant bien que mal de corriger les bugs...
18. Mais il y en a toujours plus qui arrivent
19. De plus : Il faut ajouter de nouvelles fonctionnalitées Le concurrent a sorti un nouveau concept, il faut le copier Il faut intégrer des boutons de partage social Il faut réunir plusieurs applications Le code serait vachement mieux refactoré
20. Vous n’arrivez plus à vous en sortir...
21. Vous tombez en dépression...
22. Vous démissionez...
23. Et vous vous retrouvez : Éleveur de moutons alpaga en Amérique du Sud Moine copiste en europe de l’est Loueur de planche de surf en bretagne Boulanger que vous auriez dû rester Chef de projet, c’est moins compliqué Powerpoint
24. Let’s be serious
25. Les tests ça sert à rien !
26. C’est quoi un test ? La vérification d’un objectif. Simplement: On effectue une action, on vérifie que le résultat est le résultat attendu.
27. Des tests oui... Mais automatisés Le problème avec les tests «à la main»: Il faut trouver une main disponible Dans ce cas il faut automatiser les tests
28. Pourquoi faire des tests ?
29. Pourquoi faire des tests ? Assurer la qualité du produit finit. Vérifier qu’il n’y a pas de régression. Détecter les bugs.
30. Oui mais surtout... C’est un moyen de gérer la peur pendant le développement - Kent Benck Au moindre doute, le développeur peut lancer les tests.
31. Quand faire des tests ? Idéalement, le plus tôt possible (voir avant le code cf. TDD). Plus un problème est détecté tard, plus il sera coûteux à corriger. L’un des problème des tests est qu’il demande un certain investissement.
32. L’investissement à long- terme...
33. ET à court-terme Plusieurs moyens existent pour «profiter» immédiatement des tests: Lors de la correction des bugs. 1 Bug = 1 Test Lors qu’un développeur travaille sur une partie inconnue du code. D’abord il devrait écrire des tests.
34. Que tester ? Idéalement tout, mais sinon : Se focaliser sur la logique (boucles, conditions, etc...). Pas les getters/les setters. Ne pas tester les autres librairies. Tester sur plusieurs niveaux. Commencer par les scénarios vitaux, login / inscription / paiement.
35. Bonnes pratiques Utiliser un outil d’intégration continue. Utiliser les indicateurs de tests dans le processus de déploiement. Partager les résultats des builds...
36. Et il y a le choix
37. Et il y a le choix
38. Et il y a le choix
39. Et il y a le choix
40. Et il y a le choix
41. Et il y a le choix
42. Pour aller plus loin Test Driven Development
43. Et non l’inverse !
44. Conclusion Faîtes des tests ! Même si il est impossible de tout tester, quelques tests vous simplifieront la vie !