2009-09-18 6 views
2

J'ai une classe qui a quelques tests unitaires, mais quand j'exécute des tests je voudrais que la classe soit créée avec un constructeur différent. Quelque chose comme ceci:NUnit s'exécute avec le constructeur alternatif

[TestFixture] 
public class MyClass 
{ 
    public MyClass() { /* set up for production */ } 

    [TestFixtureConstructor] 
    public MyClass() { /* set up for testing */ } 

    [Test] 
    public void FirstTest() 
    { 
     // assert some values 
    } 
} 

Est-ce encore possible?

J'ai envisagé d'utiliser une méthode d'usine statique pour créer la classe en production (avec un constructeur privé) et un constructeur public pour la structure de test.

Est-ce que quelqu'un a d'autres solutions?

Répondre

2

Si vous avez vraiment vraiment voulez cela, vous pouvez jeter un oeil à TestFixtureSetUp.

est ici l'introduction:

Cet attribut est utilisé à l'intérieur d'un TestFixture pour fournir un ensemble de fonctions qui sont exécutées une fois avant d'exécuter l'un des tests dans l'appareil. Un TestFixture ne peut avoir qu'une seule méthode TestFixtureSetUp. Si plus d'un est défini, TestFixture sera compilé avec succès, mais ses tests ne seront pas exécutés.

Exemple:

namespace NUnit.Tests 
{ 
    using System; 
    using NUnit.Framework; 

    [TestFixture] 
    public class SuccessTests 
    { 
    [TestFixtureSetUp] public void Init() 
    { /* ... */ } 

    [TestFixtureTearDown] public void Dispose() 
    { /* ... */ } 

    [Test] public void Add() 
    { /* ... */ } 
    } 
} 

Mais vous devez utiliser avec soin, ou bien elle défaites the purpose of unit test.

9

Vous ne faites pas cela.

Vous n'avez pas écrit vos tests à l'intérieur la classe que vous utilisez en code réel; vous écrivez vos tests externes aux classes. Je crois que la plupart des suites de tests ont le concept de 'Teardown' et le contraire; pour configurer l'environnement de test pour une exécution donnée.

+0

100% correct. Pour l'OP - vous ne devriez pas essayer non plus de construire des "test-only" spéciaux. Si vous avez besoin d'un constructeur pour prendre en charge les dépendances, et que la seule chose qui l'utilise est les tests, c'est bien, mais ce constructeur ne devrait pas être caché à tout le monde. Cela rend votre classe plus flexible pour les consommateurs de passer dans les dépendances. – womp

+0

Je suis d'accord. C'est absolument la mauvaise façon de faire cela. Créez une classe distincte et utilisez les attributs Setup et Teardown – lomaxx

3

Pour donner un exemple rapide de l'approche correcte Silky:

public class MyClass 
{ 
    // ... 
} 

// In a different assembly: 

[TestFixture] 
public class TestMyClass 
{ 
    [SetUp] 
    public void SetUp() 
    { 
     _myClass = new MyClass(); 
    } 

    [Test] 
    public void FooReturnsTrue() 
    { 
     Assert.That(_myClass.Foo(), Is.True); 
    } 

    // more tests 

    private MyClass _myClass; 
}