Clean Code
Extrait de la formation en ligne
PROGRAMME
(formule payante)
- 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
Pourquoi le Test Driven Development (TDD) ?
Le TDD est presque indispensable pour garder le code dans un bon état. Pourquoi ? Tout simplement parce que c’est à la fois une façon efficace d’écrire des tests – ils servent tout de suite pendant l’écriture de la fonctionnalité et permet de finir la story avec tous les tests déjà écrits – et pour couronner le tout souvent avec un excellent design.
Certes le design n’est pas automatiquement bon grâce au TDD, mais comme nous allons le voir par la suite, beaucoup de problèmes de design sont visibles dès lors qu’on essaie de tester le code. De cette manière, les tests nous poussent à nous creuser un peu plus la tête pour trouver un design qui minimise les efforts.
Mais cela ne suffirait pas de faire les tests après coup ? Peut-être, mais il y a plusieurs problèmes liés à cela :
- Nous risquons d’avoir d’autres priorités en fin de story et de ne pas écrire les tests accumulant de la dette.
- Nous risquons de ne pas régler les problèmes de design que les tests nous révèlent. En effet, quand tout le code est terminé, c’est le moment le plus cher pour tout changer.
- Nous avons consommé du temps à tester manuellement plusieurs fois avant de “finir le dev”. Lorsque nous faisons du TDD, ce temps est réduit à pas grand chose.
En résumé, le TDD permet de toujours livrer du code accompagné de tests de non régression et que ces tests servent tout de suite. Le TDD nous pousse aussi vers un design de meilleur qualité.
Le cycle TDD
Le cycle est un concept central du TDD. Nous pouvons le décrire en 3 étapes :
- Écrire un test, le voir échouer
- Faire passer le test, au plus vite
- Refactorer pour améliore le code et les tests
Contactez-nous
Vous avez des questions sur la formation ? Vous avez besoin d’un devis ? Écrivez-nous, nous vous répondrons dans les meilleurs délais.
