TDD

1. Bénéfices

1.1. Code modulaire

1.2. Le quoi en premier

1.3. Doc par l'exemple

1.4. Livraisons verticaux

1.5. Il est possible d'améliorer du code existant

1.6. Moins de debug

1.7. Quand c'est fini c'est fini

1.8. Synergie entre bon code et code testable - M. Feathers

2. Problèmes des projets

2.1. La QA prend de + en+ de temps

2.2. Qualité code en baisse

2.3. Code non souple

2.4. Validation lente

3. TDD <=> bon code?

3.1. Code testable

3.1.1. Petits objets

3.1.2. Isolation de dependences "chers"

3.1.3. Pas de duplication

3.2. Bon test

4. Histoire

5. Pourquoi?

5.1. Livrer fréquemment

5.1.1. Code simple

5.1.1.1. Refactoring

5.1.2. Non reg automatisé

5.1.3. Pourquoi?

5.1.3.1. S'adapter aux besoin

5.1.3.2. Time to market

5.1.3.3. Eviter le Standish 70%

5.2. Architecture cohérente face aux besoins non prévus

6. C'est quoi?

6.1. Cycle TDD

6.1.1. Ecrire 1 test

6.1.1.1. Le minimum de fonctionnalité

6.1.2. Faire passer le test

6.1.2.1. Le plus simple / naif / ex valeur en dur

6.1.3. Refactorer

6.1.3.1. Améliorer la solution sans ajout de fonctionnalité

6.1.3.1.1. Réduire duplication

6.1.3.1.2. Nommage

6.2. Test par test

7. Comment?

7.1. Cycle TDD

7.2. Procédure

7.2.1. Test d'acceptance

7.2.1.1. Puis x cycles TDD

7.3. Petits objets

7.3.1. Composition

7.4. Pas équilibre entre dev et test, mais intégration

7.5. S'isoler du non-testable

7.5.1. Injection

7.5.2. Test d'adapteur

7.5.3. Architecture hexagonale / ports et adapteurs

7.6. Injection