Utilisez-vous TestInitialize ou le constructeur de classe de test pour préparer chaque test? et pourquoi?

Question

Cette question concerne les tests unitaires dans Visual Studio en utilisant MSTest (ceci est important, à cause de execution order de MSTest). La méthode marquée [TestInitialize] et le constructeur de la classe de test s'exécuteront avant chaque méthode de test. Donc, la question est: qu'est-ce que vous avez tendance à faire dans chacun de ces domaines? Evitez-vous d'effectuer certaines activités dans l'un ou l'autre? Quelle est ta raison: style, technique, superstition?

Answer 1

Le constructeur est juste une structure fournie par le langage. Chaque cadre de test semble avoir son propre cycle de vie contrôlé "initialiser". Vous aurez probablement des ennuis en utilisant le constructeur pour muter vos locaux.

MSTest: Vous obtenez une instance entière de la classe de test pour chaque TestMethod. Cela peut être le seul cas où il est possible de muter vos sections locales dans le constructeur, l'initialiseur ou la méthode de test sans affecter les autres méthodes de test.

public class TestsForWhatever 
{ 
    public TestsForWhatever() 
    { 
     // You get one of these per test method, yay! 
    } 

    [TestInitialize] 
    public void Initialize() 
    { 
     // and one of these too! 
    } 

    [TestMethod] 
    public void AssertItDoesSomething() { } 

    [TestMethod] 
    public void AssertItDoesSomethingElse() { } 
} 

MSpec: Vous obtenez seulement un Establish et Because pour toutes vos affirmations (It). Donc, ne mutez pas vos locaux dans vos affirmations. Et ne dépendez pas des mutations des locaux dans les contextes de base (si vous les utilisez).

[Subject(typeof(Whatever))] 
public class When_doing_whatever 
{ 
    Establish context =() => 
    { 
     // one of these for all your Its 
    }; 

    Because of =() => _subject.DoWhatever(); 

    It should_do_something; 
    It should_do_something_else; 
} 

Answer 2

L'objet que vous testez n'a pas besoin d'être instancié dans la méthode [TestInitialize]. Vous pouvez tester le constructeur de votre objet dans une méthode de test [Test]. L'objet dans [TestInitialize] peut être pour configurer votre stockage de persistance ou pour préparer la valeur que l'objet testé utilisera dans les tests.

Answer 3

Je préfère utiliser la méthode [TestInitialize] pour effectuer l'instanciation de l'objet testé et de ses paramètres. Je n'effectue du travail dans le constructeur que s'il est nécessaire d'instancier une classe de base de test (qui est généralement l'endroit où je crée ou réactualise des dépôts, etc.). Cela m'aide à garder le code du framework de test et le code de test séparés logiquement et physiquement.

Answer 4

Cette question est également demandé (plus tard) à What’s the difference between using the constructor in VS Testing framework vs. TestInitialize() attribute?

FWIW Je suppose que par "constructeur de la classe" vous voulez dire le instance constructor (pas le static constructor).

je crois la même question que vous demandez peut également être interrogé sur le constructeur statique contre ClassInitialize ...

Answer 5

Le principal avantage d'utiliser soit TestInitialize() ou ClassInitialize() plutôt que l'instance de classe de test ou constructeurs statiques est sa nature explicite. Il indique clairement que vous faites une configuration avant vos tests. Faire cela régulièrement devrait améliorer la maintenabilité à long terme.

Answer 6

Voici quelques avantages que j'ai trouvés avec TestInitialize.

• Certaines variables d'environnement (par exemple TestContext) ne sont accessibles qu'après l'instanciation de la classe de test.
• Peut nécessiter une implémentation avec une classe dérivée en marquant un résumé de méthode TestInitialize de base.
• peut facilement remplacer une méthode de TestInitialize de base et déterminer si appeler les bases impl avant que les impl dérivés, après, ou pas du tout. En revanche, si vous dérivez une classe de test à partir d'une classe de test de base, dans le cas d'un constructeur sans paramètre, le cteur de base sera appelé si vous l'avez voulu ou non.
• Sa définition explicite rend les intentions claires et complète la méthode TestCleanup. Vous pourriez argumenter que vous pouvez créer un destructor pour chaque constructeur, mais il n'est pas garanti que MS Test gérera les destructeurs comme vous vous en doutez.

Answer 7

Cela dépend du scénario. Si vous avez une classe de test, et pour une raison étrange si vous avez besoin de créer une instance sur une autre classe de test, vous devrez utiliser le constructeur.

Sinon essai initialize plus unique dans le concept. Tout d'abord, pour les mêmes raisons que ci-dessus, la seconde MS peut introduire plus de fonctionnalités sur cet attribut et vous en bénéficierez, avec le constructeur vous y serez coincé.

Answer 8

Je dis utiliser le constructeur à moins que vous avez besoin TestContext.

1. Si vous pouvez garder les choses simples, pourquoi pas. Un constructeur est plus simple qu'un attribut magique.
2. Vous pouvez utiliser readonly qui est une grande chose dans l'initialisation de test où vous voulez préparer des choses pour les tests qu'ils ne sont pas censés changer (idéalement les choses que vous préparez serait trop immuable).