Test-Driven Development
Pourquoi ?
L'approche T.D.D. (Test-Driven Development) consiste à implémenter les tests en premier.
Cela offre les avantages suivants :
Lors de l'implémentation du test, on se concentre sur la fonctionnalité et son utilisation plutôt que sur les contraintes liées à son développement. Autrement dit, on se concentre sur ce que l'on veut faire plutôt que sur ce que l'on peut faire. Cela évite par exemple l'utilisation de librairies inadaptées.
Le T.D.D. encourage naturellement l'adoption d'architectures simples, modulaires et découplées afin de simplifier l'implémentation des tests. On obtient alors une meilleure architecture et un code moins monolithique et plus facile à maintenir.
Les interfaces peuvent être générées à partir des tests.
Quand les tests passent, on sait que la fonctionnalité est opérationnelle.
Le développement est plus rapide car la vérification des résultats est instantanée et automatique.
Le "Test-Driven Development" Etape par Etape
1. Définition du Test
Grâce à la fonction xit
de Jasmine, on peut décrire une "spec" et l'exclure tant que la fonctionnalité n'est pas implémentée.
Ce code peut être "commit" et "released".
Les tests désactivés sont affichés sur les rapports.
Par précaution, nous pouvons lever une exception dans le test pour éviter qu'il ne soit activé par erreur et que cela donne l'impression d'un test qui fonctionne.
La classe NotImplementedError
peut être implémentée ainsi.
2. Implémentation du Test
Un test désactivé sera tout de même compilé par TypeScript.
Grâce à l'IDE, on peut générer les classes et fonctions sans les implémenter.
Ce code peut être "commit" et "released".
Par précaution, vous pouvez toujours ajouter une annotation @deprecated: Work in progress
dans les commentaires de la méthode.