Visual Studio 2015中的测试执行错误（2013年工作）

Question

We are in the process of upgrading from Visual Studio 2013 Update 5 to Visual Studio 2015 Update 1.

Our Solution has many tests and we use NUnit 2.6.4, along with the NUnit Test Adapter for NUnit 2.x.

When running these tests in Visual Studio 2013, they all run perfectly well.

However, when running in Visual Studio 2015 the first 200 odd tests run, then execution stops. I can then select the tests that have not yet run and successfully execute these. I have the latest ReSharper installed in both VS2013 and VS2015 and it happily executes all the tests.

We've been keeping test-coverage details for each release since the dawn of time, and from Visual Studio's test runner it shows me the number of blocks covered. But ReSharper shows us the number of statements covered. Slightly different values, but they'd mess up our charts.

When test execution fails, it creates a Dump file (it also creates some XML files that just seem to show what DLLs I've installed). I can open this and "debug" it, but it simply shows me a line of code that fails, and the call stack shows only [Managed Code], which means I can't identify the actual test that's causing the issue.

The fact that this works perfectly in VS2013 and in ReSharper running in VS2015 suggests that "it's not our fault", but whilst I'd like to think that, it doesn't help me fix this.

Any ideas?

Thanks

Griff

Answer 1

Tracked down the problem. We had one class in our Solution that implements IDispose and one of our Unit tests didn't dispose of that class, it just allowed it to go out of scope.

So because the Disposable object hadn't been disposed, the class' Finalizer hadn't been suppressed. The GC therefore called the Finalizer which in turn attempted to access another object that had also gone out of scope, resulting in an exception that crashed the Test Execution Runner.

Interesting that VS2015 running NUnit 2.x crashes, but the identical setup in VS2013 copes fine.

As an aside, when debugging the DUMP file (see above), I realized that the call stack was irrelevant, I just had to put in some defensive coding in the Finalizer.