2009-11-02 12 views
3

Beaucoup de nos tests système sont écrits dans un style BDD, et nous utilisons assez bien les comportements hérités pour minimiser la duplication, par exemple cela pourrait être une hiérarchie de base pour les tests d'achat.Existe-t-il un cadre de style BDD qui autorise plusieurs comportements hérités?

class BehavesLikeSuccessfulPurchase 
class BehavesLikePurchaseWithValidCreditCard : BehavesLikeSuccessfulPurchase 

Dans ce cas, le BehavesLikeSuccessfulPurchase définit les comportements communs comme le relevé de compte devrait avoir une entrée de débit, et la classe BehavesLikePurchaseWithValidCreditCard définit le flux de travail de test pour l'achat de tout type de produit avec une carte de crédit valide, de sorte que les essais sont petits classes dérivées qui fournissent simplement l'instance de produit concrète, par exemple

[Concern(typeof(Video))] 
class WhenPurchasedWithValidCreditCard : BehavesLikePurchaseWithValidCreditCard 

Cependant, en fonction du type de produit en béton nous avons également besoin d'avoir des contrôles supplémentaires, par exemple chaque fois est acheté avec succès une vidéo que nous voulons vérifier qu'il est ajouté à la bibliothèque vidéo de l'utilisateur. Idéalement, cela pourrait être défini par une autre classe et on mélange, en utilisant la syntaxe hypothétique:

class BehavesLikeSuccessfulVideoPurchase 

[Concern(typeof(Video))] 
class WhenPurchasedWithValidCreditCard : BehavesLikePurchaseWithValidCreditCard 
    mixin BehavesLikeSuccessfulVideoPurchase 
{ 
} 

Mais bien sûr, C# ne prend pas en charge l'héritage multiple ou mixins si nous finissons par écrire une charge de méthodes passe-partout qui avant appelle aux comportements supplémentaires, qui doit changer chaque fois que ce comportement change. Ce dont nous avons vraiment besoin, c'est d'un cadre qui possède son propre mécanisme de prise en charge de multiples comportements à partir de tests simplement en fournissant le (s) type (s) de comportements supplémentaires qui doivent être observés. J'ai regardé xUnit et les exemples de spécifications, et il semble qu'il serait possible de trouver des extensions qui pourraient faire l'affaire, mais existe-t-il déjà quelque chose?

Répondre

3

Le projet Machine.Specifications a cette idée, vous pouvez spécifier une classe avec l'attribut Behaviors, puis dans une autre classe, spécifiez

Behaves_like<SomePredefinedBehaviour> some_predefined_behaviour; 

plus d'une fois dans le cahier des charges, ce qui vous permet d'hériter le comportement d'aussi beaucoup de cours que vous aimez. Le style prend un certain temps à s'habituer à partir d'un arrière-plan de test unitaire traditionnel, mais il prend en charge le comportement. Si vous téléchargez le projet et regardez les exemples, vous en verrez un avec des comportements.

0

En utilisant Linfu vous pouvez faire Mixins: http://www.codeproject.com/KB/cs/LinFuPart2.aspx

Ce que je ne suis pas sûr de bien, est si le cadre BDD joue bien avec des objets dynamiques Linfu.

Je n'ai pas eu l'occasion d'utiliser moi-même les Mixins de LinFu, je serais donc curieux de savoir à quel point ils sont faciles/complexes dans un scénario modérément complexe et s'il y a des inconvénients majeurs.