/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
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.
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
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
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)
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é
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
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
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.
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.
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.
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...
lothiraldan
speed1313
track3jyo
daiksy
ogijun2018
coe401_
utgwkk
maroon1st
tanakahisateru
tkmnzm
dosukoi_android
m_seki
yoshikouki
akmur
bkeepers
caitiem20
phodgson
keavy
chriscoyier
keithpitt
frogandcode
kneath
maggiecrowley
jmmastey
destraynor