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 don't believe that there are many instances in which a lengthy test init is actually required. It would be interesting to know what kind of operations were being included in the poster's example.
A bit of creativity is required to separate a TestInit's functions into ClassInit (someone earlier suggested use of a constructor... kind of the same thing, but errors in that block of code will report quite differently). For example, if every test need a List<> of strings that's read from a file, you split it this way:
1) ClassInit - read the file, capture the strings into an array (the slow part) 2) TestInit - copy the array's elements into a List<> accessible by each test (the fast part)
I'm against using statics to try to solve a test performance problem, it ruins each test's isolation from each other.
I'm also against tests using things like StopWatches to assert on their own performance... running tests generates a report, so watchers of that report should identify tests that run too long. Also, if we want automated tests to exercise the performance of something, that's not a unit test, that's a performance test, and it can (should?) be something entirely different.