Le document aborde la méthode de développement TDD et le principe de l'ouverture/fermeture (OCP) à l'aide du kata FizzBuzz. Il présente les avantages du TDD, notamment l'amélioration du code et la réduction des débogages, et explique comment intégrer de nouvelles fonctionnalités tout en respectant OCP. Des exemples de règles supplémentaires et de planification de refactoring sont également discutés pour maintenir un design efficace et éviter l'over engineering.

1. Dojo TDD & OCP
Open close principle with FizzBuzz kata
Sylvain Bonnard @CharlesBouttaz

2. TDD : Red, Green, Refactor...

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 :(

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

8. Changer de comportement sans changer le code source

10. Refactoring préparatoire

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é

14. Sources
- http://fr.slideshare.net/xpmatteo/20101125-ocpxpday