This is the kind of question that treads the gray area between StackOverflow and SuperUser. As I suspect the answer is likely to involve code-related solutions, such as crea
I discovered today a method of handling expensive initialization in MSTest without it causing the tests to report as slow. I post this answer for consideration without accepting it because it does have a modest code smell.
MSTest creates a new instance of the test class each time it runs a test. Because of this behavior, code written in an instance constructor occurs once per test. This is similar behavior to the [TestInitialize]
method with one exception: MSTest begins timing the unit test after creating the instance of the test class and before executing the [TestInitialize]
routine.
As a result of this MSTest-specific behavior, one can put initialization code that should be omitted from the automatically-generated timing statistics in the constructor.
To demonstrate what I mean, consider the following test and generated output.
Test:
public class ConstructorTest
{
public ConstructorTest()
{
System.Threading.Thread.Sleep(10000);
}
[TestMethod]
public void Index()
{
}
[TestMethod]
public void About()
{
}
}
Output:
My Thoughts:
The code above certainly produces the effect I was looking for; however, while it appears safe to use either a constructor or a [TestInitialize]
method to handle initialization, I must assume that the latter exists in this framework for a good reason.
There might be a case made that reports including initialization time in their calculations might be useful, such as when estimating how much real time a large set of tests should be expected to consume.
Rich Turner's discussion about how time sensitive operations deserve stop watches with assertions is also worth recognizing (and has my vote). On the other hand, I look at the automatically generated timing reports provided by Visual Studio as a useful tool to identify tests that are getting out of hand without having to author timing boilerplate code in every test.
In all, I am pleased to have found a solution and appreciate the alternatives discussed here as well.
Cheers!