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.

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 ?