TDD dans la vraie vie

Tout le monde s’accorde pour dire que le TDD c’est bien, mais peu de personnes le pratiquent au quotidien.
Cette pratique semble bien sympa quand on voit une démo sur un petit algo, mais finalement le code de nos projets ne ressemble pas trop à ça. Notre quotidien est plutôt rempli de contrôleurs, bases de données, classes de service et divers dépendances difficiles à tester.
Nous vous proposons de montrer comment nous travaillons avec des tests en TDD pour construire une petite application REST connectée avec une base de données.
Nous discuterons aussi de ce que nous considérons être un test utile et comment cela change avec l’âge du projet.

Transcript

1. TDD de la vraie vie AlpesCraft 2022
2. Qui sommes-nous ? Johan MARTINSSON Coach tech Dev Xavier NOPRE Artisan Développeur CTO @ vrtice
3. Constat / Notre but • Intérêt des tests unitaires ? ⇒ OK pour beaucoup de monde ! • Qui pratique le TDD régulièrement ? ⇒ … 😕 • Quel est le problème ? ⇒ Passage à l’acte au quotidien ⇒ Montrer notre approche du TDD pour la vraie vie !
4. TDD vs Test After End of story Changing the code again No value until code is changed
5. TDD : comment ? Remaniements, mise au propre, nommages, factorisations, … 1 test qui ne passe pas pour de bonnes raisons Code “minimum” pour faire passer ce test
6. De la valeur au plus tôt ! • TDD sur du code algorithmique ⇒ OK mais éloigné de notre quotidien • "Ecrire une spécification exécutable" n'est pas spécifique au "bas niveau" ◦ Cela se fait aussi bien à tout niveau comme par exemple sur des “test d’intégration”
7. De la valeur au plus tôt ! • TDD sur algo ⇒ OK mais éloigné de notre quotidien • "Écrire une spécification exécutable" ⇏ "bas niveau" ◦ TDD 💕 tous les tests
8. Démo Vous verrez • Du TDD en action • Une approche de TDD basée sur l’usage ◦ “Test d’intégration” Vous ne verrez pas • De la logique métier complexe • Du DDD • De l'archi hexagonale • Du code très propre
9. Vous verrez • TDD en action • Du TDD sans TU Vous ne verrez pas
10. Démo : contexte • Application de vote pour votre langage préféré ! • Prototype front en approche “front first”
11. Démo !
12. Le risque de devoir changer les tests 😱
13. Problème Modifier une interface sous test ⇒ • Pas de protection • Modification du test Comment reconnait-on une interface stable 🤔 ? 1. Proche du besoin utilisateur/client 2. Vielle 3. Le ratio surface / volume faible. 💡 Testons des interfaces stables
14. A retenir • + Le TDD ça vaut le coup, et c’est faisable dans la vraie vie • Respectez le cycle du TDD et les règles de base (pour apprendre) • + Le TDD n'a rien à voir avec le type du test • Ecrivez les tests qui vous aide à avancer et vous apporte vite de la valeur • + Au début, le TDD est plus intéressant avec les tests proches de l’usage ◦ Plus tard dans une story ou dans un projet les tests bas niveau sont incontournables • Le besoin côté utilisateur est connu au début et stable dans le temps • Le feedback immédiat a de la valeur
15. A retenir • Le TDD ça vaut le coup, et c’est faisable dans la vraie vie • Le TDD n'a rien à voir avec le type du test ◦ On ne doit pas forcément faire du TDD sur des tests unitaires bas niveau • Pour du TDD sur du code nouveau, des tests proches de l’usage peuvent être plus intéressants ◦ Plus tard dans une story ou dans un projet les tests bas niveau sont incontournables
16. Merci ! Des questions ?