79

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?

riQQ
  • 9,878
  • 7
  • 49
  • 66
Anthony Mastrean
  • 21,850
  • 21
  • 110
  • 188

11 Answers11

65

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;
}
Anthony Mastrean
  • 21,850
  • 21
  • 110
  • 188
  • I had the same issue and you just provided the right explanation, thanks! – Raffaeu Apr 11 '13 at 08:28
  • 7
    You might also point out that `[ClassInitialize]` is only run once per Test Run (prior to the everything), so it can be used for any expensive setup routines. – kmote Oct 30 '13 at 22:10
  • 5
    -1: You should not hate your question; it makes much sense, actually. See, for example, [xUnit.net](https://github.com/xunit/xunit): it recommends using the constructor as *the* test case initializer. Being "just a structure provided by the language" is not a small matter; anyone writing any kind of framework (test frameworks included) should *not* try to reinvent the wheel, and make use of well defined standards instead (like, you know, using constructors for initializing stuff, and so on). – rsenna Jun 16 '15 at 14:52
  • 3
    It's amazing how Microsoft can write a whole web page and not give the basic information you gave in this simple straight forward answer. Good job. – toddmo Mar 24 '16 at 16:38
  • @toddmo Sometimes they don't give all the info because it is considered an implementation detail that might change in the future. That being said, it may not be wise to write code that depends on an undocumented behavior. This is why I favor `[TestInitialize]` attribute instead of constructors. – Milos Mrdovic May 28 '18 at 16:51
  • Should a test class be `sealed` or `abstract` ? or even `static` – Yousha Aleayoub Aug 04 '21 at 07:31
26

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.
T. Webster
  • 9,605
  • 6
  • 67
  • 94
  • 2
    I found that MSTest *does* run a `public void Dispose` method after each test run. It must be public, and it doesn't matter you implement `IDisposable`: you cannot explicitly implement the interface. – Sebazzz Aug 29 '16 at 18:21
15

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.

Romi
  • 175
  • 1
  • 2
  • 12
    I disagree. What could clearer than a constructor? Sure, you have to know you get a new test class instance for each test, but that's something you really should know anyway. And it's not like `TestInitialize` is such an obvious name that can't cause any confusion: https://stackoverflow.com/questions/22999816/testinitialize-vs-classinitialize. – Ohad Schneider Jul 23 '17 at 21:52
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).
Ohad Schneider
  • 36,600
  • 15
  • 168
  • 198
  • 2
    +1 for the readonly. I just deleted my question about it when i saw your answer. But i usually would think in the other way: i use the TestInitialize unless i want a readonly attribute, since it looks a better "language" fit in test context. But it is just a design decision. I am ok with both approachs. – heringer Nov 10 '17 at 16:29
4

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.

Anthony Mastrean
  • 21,850
  • 21
  • 110
  • 188
4

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");
        }
jps
  • 20,041
  • 15
  • 75
  • 79
sschoof
  • 1,531
  • 1
  • 17
  • 24
3

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

Community
  • 1
  • 1
bacar
  • 9,761
  • 11
  • 55
  • 75
2

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.

Rook
  • 5,734
  • 3
  • 34
  • 43
Patrick Desjardins
  • 136,852
  • 88
  • 292
  • 341
  • 2
    I know this. You can instantiate the object inline with the declaration if possible. My question is what do _you_ do in either of those places. And why? – Anthony Mastrean Dec 02 '08 at 16:21
  • 7
    You didn't answer that question in your answer. Read the question again. – Slauma Jan 23 '11 at 21:25
0

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.

Teoman shipahi
  • 47,454
  • 15
  • 134
  • 158
0

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: enter image description here

Hope this will be helpful for somebody

Jevgenij Kononov
  • 1,210
  • 16
  • 11
0

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.

Naod Agere
  • 39
  • 1
  • 6
  • Posting a documentation does not answer the OP's question: `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?` – HardcoreGamer Aug 29 '23 at 04:19