Merci pour vos réponses argumentées 🙏
Avec les années – 17 ans de pratique du TDD and counting – mes habitudes se sont stabilisées ainsi :
1️⃣ j’essaie toujours d’introduire un maximum de fonctions pures (input / output, pas d’état interne) dans mes logiciels, quitte à inventer des mini-théories transformationnelles pour aider.
J’extrais un maximum vers des libs open-source.
TDD guidé par les tests unitaires des API publiques. Test first : red, green, refactor.
Pas d'état => pas besoin de mock, stub et autres.
API publiques => la suite de tests est stable.
2️⃣ Dans les backend des clients je fais du TDD guidé par des tests d’intégration. Ces tests ciblent les API web publiques (p.ex. Restful ou JsonRPC).
Ici j’ai une méthode secrète qui me vient de mes années de recherche : chaque API est vue comme une opération de haut niveau qui a un INPUT, un OUTPUT, et des PRE-conditions, POST-conditions et ERR-conditions sur l’état applicatif.
Ma lib open-source webspicy permet de décrire ces spécifications de manière langage-agnostic et d’y attacher des tests tests positifs (la PRE est correcte, on teste les POST) et négatifs (une PRE est violée, on teste les ERR).
L’état applicatif est réel, sauf mock de composants tiers (p.ex. serveur mail). Webspicy supporte la vérification des schémas de données INPUT & OUTPUT, la gestion et inspection de l’état, la génération de tests de robustesse, etc.
3️⃣ Côté front j’extrais un maximum de logique métier comme pour 1️⃣ ci-dessus. Pour le reste j’ai parfois des end-2-end gherkin cypress, mais c’est pas du TDD chez moi. Je n’ai pas trouvé de setup qui me plaise jusque là et les tests manuels restent trop importants à mes yeux.
#TDD #SoftwareEngineering #Agile