3. TDD : les intérêts
● Test first : Qu’est ce que je dois faire ?
● Meilleur code & meilleur design *
○ Unitaire -> découplé
○ Design émergent : moins d’over engineering
● Est ce que j’ai cassé quelque chose ?
○ Moins de debug
○ Plus d’excuses pour ne pas améliorer le code
4. Notre startup : FizzBuzz!
- Le programme prend un chiffre en entrée et l’affiche sur la console
- Si le nombre est un multiple de 3 on affiche : Fizz!
- Si le nombre est un multiple de 5 on affiche : Buzz!
- Si le nombre est un multiple de 3 et de 5 on affiche : FizzBuzz!
5. Limite de l’approche if
On fait un carton sur Facebook : Champagne :)
Le marketing veut intégrer 15 nouveaux mot-clés :(
6.
7. Open/Closed Principle
- SOLID
- “Software entities (classes, modules, functions, etc.) should be open for extension,
but closed for modification”
- Changer de comportement sans changer son code source
11. Nouveau workflow TDD & OCP
Nouvelle règle : Si le nombre est un multiple de 7 on affiche : Bang!
On commence par écrire un test rouge
Est ce que je peux ajouter la nouvelle fonctionnalité uniquement en changeant le code
de construction (constructeur / factory) ?
● oui -> j’ajoute ma feature
● non -> je refactor jusqu’a pouvoir ajouter ma fonctionnalité sans violer OCP
12. Règles supplémentaires
● Boum (%10)
● Mode easy (fizzbuzz) / medium (FB+Bang) / hard (FB+Bang+Boum)
● Affichage : Si on a que Fizz on affiche FIZZ
13. Conclusion
Rappels :
- Avant de coder, on refactor pour rendre l’implémentation plus facile
- Avant de “refactorer”, reflechir et planifier
- Toujours refactorer avec des tests verts
- Si vous vous trompez, ctrl-Z jusqu’à l’état vert
- Attention au design prématuré : en créant des extensions on augmente la
complexité