Clean Code
Extrait de la formation en ligne
PROGRAMME
- Tester c’est douter, la qualité coûte cher
- 🔒 Live #1 : faisons connaissance
- D’où vient la dette technique
- 🔒 Configurer son environnement pour les tests
- La couverture du code
- Exercice ouvrir du code existant
- 🔒 L’obsession des primitives
- 🔒 Exercice : refactoring protégé par les tests
- Le cycle TDD
- 🔒 Exercice : un premier bout de code en TDD
- 🔒 Comment gagner du temps grâce à la qualité ?
- 🔒 Les indicateurs pour suivre ses progrès
- 🔒 Live #2
- 🔒 Protéger un code existant avec des tests
- 🔒 S’assurer de la couverture du code
- 🔒 Tester c’est documenter
- 🔒 Refactorer pour préparer une nouvelle fonctionnalité
- 🔒 Introduire la nouvelle fonctionnalité en TDD
- 🔒 Les bases du pair-programming
- 🔒 Live #3
- 🔒 Les bases des Stubs (bouchons), s’isoler des dépendances non testables
- 🔒 Les bases de Spies (espions), tester des méthodes
- 🔒 Et les Mocks (simulacres) dans tout ça ?
- 🔒 Stratégie #1 : Éliminer les Stubs
Stratégie #2 : - 🔒 Introduire une couture (Seam)
- 🔒 Et si vous n’aimez pas les Stubs et les Spies ?
- 🔒 Éviter les bugs de spécifications, travailler avec des exemples
- 🔒 Éliminer les exceptions
- 🔒 Dé-duplicaquer le code (et les tests)
- 🔒 Réduire le besoin de mise à jour des tests
- 🔒 Séparer le code testable du code non testable
- 🔒 Tester le code non testable (tests d’intégration ciblés)
- 🔒 Organiser un coding dojo avec son équipe
- 🔒 Concevoir sa stratégie de tests avec la pyramide des tests
- 🔒 Parler de la dette technique à son sponsor
- 🔒 Gérer la dette technique dans son backlog produit
- 🔒 Live #5
- 🔒 Bibliographie
- 🔒 Rappels des concepts objet
- 🔒 Maîtriser son IDE
- 🔒 Intégration continue
- 🔒 Déploiement continu
- 🔒 BDD (Behaviour Driven Development) pour faire du TDD
Bienvenue !
Ce module gratuit est extrait de la formation en ligne “Clean code, sortir de la dette technique“.
Accédez directement aux 5 séquences du module 1 :
Tester c'est douter, la qualité coûte cher
Dans cette séquence, j’aborde l’idée reçue selon laquelle la qualité coûte cher. Ce constat, que je ne partage pas, vient souvent d’une vision du travail par activité. Dans ce cas, on l’aborde d’abord par spécification puis par le développement, par le test, et enfin par le déploiement. Cette approche pousse à optimiser le temps de chaque activité indépendamment des autres, ce qui est une véritable fabrique à bugs pour chaque phase.
C’est la perte de temps due à ces retours que l’approche qualité cherche à éliminer. Pour se rendre compte de l’efficacité, il faut mesurer le temps total.
Par conséquent, si nous voulons augmenter la qualité, nous avons intérêt à changer de vision et de mesure.
