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 t

Answer 1

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 2

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 3

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