Do you use TestInitialize or the test class constructor to prepare each test? and why?

Question

This question regards unit testing in Visual Studio using MSTest (this is important, because of MSTest's execution order). Both the method marked [TestInitialize] and the test class constructor will run before each test method.

So, the question is, what do you tend to do in each of these areas? Do you avoid performing certain activities in either? What is your reason: style, technical, superstition?

Answer 1

MSTEST0020: Prefer constructors over TestInitialize methods

Answers it:

https://learn.microsoft.com/en-us/dotnet/core/testing/mstest-analyzers/mstest0020

Answer 2

This is what the MS document says: The TestInitialize is similar to the class constructor but is usually more suitable for long or async initializations.

Answer 3

With async there is another reason (that did not exist when this question was asked) for [TestInitialize]. It allows you to do async operations to setup (eg. load a file) which is not possible in the constructor:

        private string approver;        

        [TestInitialize]
        public async Task Initialize()
        {
            approver = await File.ReadAllTextAsync("approver.json");
        }

Answer 4

I hope somebody still needs that. This is my solution, how to unit test class constructor. I am unit testing class service and throwing an exception if debuggingService is null.

DebuggingStepTests class constructor

private readonly IDebuggingService debuggingService;

public string StepName { get; set; }

public DebuggingStep(IDebuggingService _debuggingService)
{
    _log.Starting();
    StepName = "DebuggingStep";

    debuggingService = _debuggingService 
        ?? throw new ArgumentException("DebuggingStep init failure due to => IDebuggingService null");
}

UnitTests looks like this

    [Fact]
public void TestDebuggingStepConstructorWhen_InitServiceIsNull_ResultArgumentException() 
{
    //Arrange
    var arrange = new Action(() => 
    {
        new DebuggingStep(null);
    });

    //Act

    //Arrange
    Assert.Throws<ArgumentException>(arrange);
}

And actual result:

Hope this will be helpful for somebody

Answer 5

The object you test doesn't need to be instantiated in the [TestInitialize] method. You can test the constructor of your object in a test method [Test].

Object in the [TestInitialize] can be to setup your persistance storage or to prepare value that the object tested will used in the tests.

Answer 6

I say use the constructor unless you need TestContext.

1. If you can keep things simple, why not. A constructor is simpler than a magical attribute.
2. You can use readonly which is a big thing in test initialization where you want to prepare stuff for the tests that they're not supposed to change (ideally the stuff you prepare would be immutable too).

Answer 7

The constructor is just a structure provided by the language. Every test framework seems has its own controlled lifecycle "initialize". You'll probably only get into trouble using the constructor to mutate your locals.

MSTest: You get an entire new instance of the test class for every TestMethod. This might be the only case where it's ok to mutate your locals in the constructor, initializer, or test method and not affect the other test methods.

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: You only get one Establish and Because for all your assertions (It). So, don't mutate your locals in your assertions. And don't depend on mutations of locals in base contexts (if you use them).

[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 8

It depends on the scenario. If you have a test class, and for some weird reason if you need to create instance of it on another test class, you will need to use constructor.

Otherwise test initialize more fits in the concept. Firstly, same reasons written above, second MS can introduce more features on that attribute and you will benefit them, with constructor you will stuck into it.

Answer 9

Here are some advantages I've found with TestInitialize.

• Some environmental variables (e.g. TestContext) are not accessible until after the test class is instantiated.
• Can require implementation with derived class by marking a base TestInitialize method abstract.
• Can easily override a base TestInitialize method and determine whether to call the base impl before the derived impl, after, or at all. In contrast, if you derive a test class from a base test class, in the case of a parameterless constructor, the base ctor will be called whether you intended it to or not.
• Its explicit definition makes the intentions clear, and complements the TestCleanup method. You might argue that you can create a destructor for every constructor, but it's not guaranteed that MS Test will handle destructors as you'd expect.

Answer 10

The main advantage of using either TestInitialize() or ClassInitialize() rather than the test class instance or static constructors is its explicit nature. It clearly communicates that you are doing some setup prior to your tests. Doing this consistently should improve maintainability in the long run.

Answer 11

This question is also asked (later) at What’s the difference between using the constructor in VS Testing framework vs. TestInitialize() attribute?

FWIW I assume by "class constructor" you mean the instance constructor (not the static constructor).

I believe the same question you are asking could equally be asked about the static constructor vs. ClassInitialize...

Answer 12

I prefer to use the [TestInitialize] method to perform instantiation of the object being tested and it's parameters. I only perform work in the constructor if it is necessary to instantiate a testing base class (which is usually where I create or refresh repositories, etc). This helps me keep the test framework code and test code separate logically and physically.