SetUp dans les classes dérivées avec NUnit?

Question

Si j'ai le code suivant:

[TestFixture] 
public class MyBaseTest 
{ 
    protected ISessionManager _sessionManager; 

    [SetUp] 
    public void SetUp() { /* some code that initializes _sessionManager */ } 
} 

[TestFixture] 
public class MyDerivedTest : MyBaseTest 
{ 
    IBlogRepository _repository; 

    [SetUp] 
    public void SetUp() { /* some code that initializes _repository */ } 

    [Test] 
    public void BlogRepository_TestGoesHere() { /* some tests */ } 
} 

... NUnit ne pas appeler la routine de base SetUp. C'est prévu, et je n'ai pas de problème avec lui-même. Je peux obtenir le SetUp dérivé d'appeler la configuration de la base première, comme ceci:

[TestFixture] 
public class MyDerivedTest : MyBaseTest 
{ 
    IBlogRepository _repository; 

    [SetUp] 
    public new void SetUp() 
    { 
     base.SetUp(); 
     /* some code that initializes _repository */ 
    } 

C'est laid. Si c'était un constructeur, je n'aurais pas à le faire.

je pourrais utiliser le modèle « méthode de modèle », et ont les éléments suivants:

public void MyBaseTest 
{ 
    abstract void SetUp(); 

    [SetUp] 
    public void BaseSetUp() 
    { 
     /* base initialization */ 
     SetUp(); // virtual call 
    } 
} 

Je ne suis pas particulièrement friand de ce fait, non plus.

Que faites-vous lorsque leurs classes de test ont besoin de SetUp et qu'elles sont dérivées d'une autre classe qui nécessite également SetUp?

Answer 1

Vous devez appeler la méthode directement.

[SetUp] 
    public void DerivedSetUp() 
    { 
     base.BaseSetUp(); 
     // Do something else 
    } 

Éditer: Je ne l'ai pas essayé, mais peut-être qu'une méthode partielle pourrait fonctionner aussi. Je préférerais faire les choses ci-dessus.

Édition2: Je viens d'essayer d'utiliser des méthodes partielles. Ça n'a pas marché. Même si c'était le cas, je pense qu'il sera toujours plus facile d'appeler la classe de base.

Answer 2

Vous avez explicitement la classe de base. Étant donné que NUnit utilise l'attribut [Setup] pour marquer la configuration du test, je pense que c'est la bonne chose à faire pour NUnit, car il suit les règles de langage habituelles. Bien sûr, NUnit pourrait rechercher les classes de base, et appeler leurs fonctions de configuration automagiquement, mais je pense que cela serait plutôt surprenant pour la plupart des gens.

Il existe cependant au moins un cadre de test unitaire qui utilise des constructeurs pour la configuration: xUnit.Net. Ici, la configuration de la classe de base est appelée automatiquement, car c'est ainsi que se comportent les constructeurs en C#.

(Notez, cependant, que xUnit.Net recommande d'utiliser à nouveau la configuration de test.)

Answer 3

Les travaux suivants MbUnit. Cela peut aussi fonctionner dans NUnit.

[TestFixture] 
public abstract class Base { 
    [SetUp] 
    public virtual void SetUp() { 
     //Some stuff. 
    } 
} 

public class Derived : Base { 
    public override void SetUp() { 
     base.SetUp(); 
     //Some more stuff. 
    } 
    [Test] 
    public virtual void Object_WhenInACertainState_WhenAMethodIsCalled_Throws() { 
     //Create and set state on the object. 
     //Call the method. 
     //Assert the method threw. 
    } 
} 

Answer 4

Une approche que j'utilise que j'ai appris dans le FireStarter TDD à Tampa était d'avoir la méthode de configuration de la classe de base, puis d'avoir une méthode virtuelle dans la classe de base appelée observer. Cette méthode est ensuite appelée dans la classe de base à la fin de la méthode d'installation. Ensuite, ce que vous faites dans la nouvelle classe dérivée de la classe de base, vous remplacerez la méthode d'observation. L'astuce dans ce scénario est que vous voulez exécuter la méthode d'installation de la classe de base et la classe enfant n'a pas une méthode d'installation. La raison de ceci est le code que vous avez dans la méthode d'observation sont seulement les choses supplémentaires dont vous avez besoin pour la classe de test de l'enfant. Cette approche fonctionne bien pour moi, mais je pense que le coureur de test voudra exécuter les tests de la classe de base, donc ce que je fais pour contourner cela est de déplacer les tests de la classe de base dans une nouvelle classe dérive de la base si j'en ai.

Answer 5

Il semble que vous souhaitiez que le programme d'installation soit exécuté une fois avant le début du test, pas une fois avant que chaque test ne soit exécuté. L'annotation [SetUp] fait que la méthode s'exécute une fois avant chaque test dans votre appareil. [SetUp] n'est pas hérité. L'annotation que vous voulez utiliser est [TestFixtureSetUp] qui est exécutée une seule fois, avant que l'un des tests d'un appareil ne soit exécuté. Ceci est hérité de la manière que vous attendez. :)

Voir the TextFixtureSetUp docs