🎯 Intention

Le TDD permet de construire le logiciel par petites itérations, en introduisant progressivement chaque use-case sous forme d’un test, puis de s’assurer que le code réponde à cette contrainte.

Ce geste de production permet au développeur de “découvrir progressivement” la solution technique répondant avec justesse au besoin tout en ayant une complexité minimale.

On obtient donc un logiciel mieux conçu, mieux testé et plus fiable, autrement dit de meilleure qualité.

Remarque : Beaucoup de spécialistes considèrent que la bonne manière d’écrire des tests est de tester des comportements (Behaviors), c’est pourquoi nous ne distinguerons pas BDD (Behavior Driven Development) et TDD (Test Driven Development). La plupart des livres et articles font références au TDD c’est pourquoi nous utilisons principalement ce terme chez Captive.

<aside> ✅ Pré-requis

• Vous connaissez la différence entre Test un comportement VS Tester une implémentation :
• Vous maitrisez les bases d’un framework de test (rspec, jest, etc) </aside>

✅ Points clés

https://www.youtube.com/watch?v=kqpHL_V1pUU

• Test isolé : il ne doit pas dépendre de l’état d’un autre test
• Test rapide en exécution | On part du besoin utilisateur et on essaie de le transcrire en langage de programmation sous forme d’un test. Le fait de visualiser que le test ne passe pas permet de s’assurer que l’on va bien rajouter une nouveau comportement au système. La qualité du test (rapidité, isolation) permet de garantir la vélocité du développeur. | | 🟢 Ecrire le code pour faire passer le test | - Il faut écrire le minimum de code de production pour que le test passe.
• Structurer le test en 3 blocs Given-When-Then | On cherche à être aussi véloce que “l’ingénieur StackOverflow”. On s’autorise à utiliser du code “naif” ou considéré comme “pas propre”. Du moment qu’il est produit rapidement et qu’il fait passer les tests | | ♻️ Refactor du code | - On cherche à obtenir du “Clean Code”
  • Rendre le code standard
  • Supprime la duplication
  • Supprime les mauvaises pratiques
• Les tests ne doivent pas être modifiés
• On ne modifie que l’implémentation interne | On cherche à maitriser la dette technique précédemment introduite. Le fait d’avoir déjà un code qui “marche” permet de refactoriser une ou plusieurs fois sans rien casser. |

❌ Erreurs type à éviter

Faire un mauvais geste de production :

• Ecrire plusieurs tests d’un coup, puis les faire passer tous
• Faire de l’over-engineering à l’étape #2

Ecrire un mauvais test :

• Tester les détails d’implémentation au lieu de l’API publique
• Créer des tests non isolés (partagés des états, utiliser des fixtures entre les tests)