2010-06-03 6 views
4

J'essaie de mettre en œuvre le modèle de stratégie en utilisant TDD. Chaque élément de stratégie implémente une interface. Quelle est la meilleure façon de le faire avec TDD?TDD avec motif de stratégie

Devez-vous créer un banc de test pour chaque implémentation de l'interface testant les mêmes méthodes mais sur chaque implémentation?

Tous les articles portant sur l'approche à adopter seraient accueillis avec gratitude :)

+0

Qu'entendez-vous par appareil d'essai? Voulez-vous dire suite de tests? –

+0

Désolé, ça allait avec la terminologie NUnit. TestFixture comme dans une seule classe contenant des méthodes de test – ChoccyButton

+0

Voici un article intéressant à ce sujet:> [** TDD kata pour la construction de la stratégie > Motif dans un modèle de domaine **] (http://codingsolutions.blogspot.com/2010/05 /tdd-kata-for-building-strategy-pattern.html) >> [Code] (http://github.com/dgadd/TDD-Kata--Strategy-Pattern-for-Domain-Model) –

Répondre

1

Je pense que je voudrais écrire une classe de test pour chaque mise en œuvre de la stratégie.

Vous pouvez créer une classe abstraite dont tous hériteront. Cela vous aidera à vous assurer que vous mettez en œuvre tous les tests pour chaque stratégie, mais présente le léger inconvénient que vous devez implémenter des méthodes stub au moins avant que chaque classe de test ne compile.

2
  1. écrire un test qui échoue
  2. écrire le code laid pour faire ce test de passage
  3. Refactor pour rendre le code plus

Dans l'étape 2, écrire du code qui n'applique pas la Modèle de stratégie (chose la plus simple qui fonctionne, même si le code dupliqué est présent).

Ensuite, à l'étape 3, vous refactorisez chaque classe, une à la fois, vers le modèle de stratégie si cela est toujours logique. Si vous faites vraiment du TDD, alors vous ne commencez pas avec un pattern - vous y référez.

+0

Cela ne répond pas vraiment à rien. Oui, vous pouvez le faire de cette façon. Mais un développeur expérimenté peut repérer des modèles à un kilomètre. Ma question est donnée que vous savez que le modèle de stratégie est la bonne solution, quelle est la structure correcte pour les cas de test – ChoccyButton

+1

Mon esprit est définitivement déformé de BDD - les cas de test devraient décrire le comportement souhaité de la classe. Les détails de la mise en œuvre de la classe ne doivent pas être évidents à partir des cas de test. Pour être DRY, vous pouvez tester un grand nombre de fonctionnalités de base dans une classe générique qui implémente l'interface - ou simplement autoriser un peu de duplication dans les tests pour chaque élément de stratégie. – ryw