Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Faites des tests - Djangocong 2013

410e3353165c33043ab69be7fc366428?s=47 Boris Feld
September 28, 2013

Faites des tests - Djangocong 2013

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

410e3353165c33043ab69be7fc366428?s=128

Boris Feld

September 28, 2013
Tweet

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
  13. None
  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 !