Clean Code

Extrait de la formation en ligne

PROGRAMME

(formule payante)

  • 🔒 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 :

  1. Nous risquons d’avoir d’autres priorités en fin de story et de ne pas écrire les tests accumulant de la dette.
  2. 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.
  3. 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
Shopping Cart
Retour haut de page