views:

25

answers:

1

I am using NUnit asserts within a MSTest project like as follows (NOTE: This shouldn't matter see comments to Dave Falkner's answer):

using Microsoft.VisualStudio.TestTools.UnitTesting;
using MSTestExtensions;
using Assert = NUnit.Framework.Assert;
using Is = NUnit.Framework.Is;

This has worked great in my unit tests, but in my integration tests I am having some trouble. I think it might be due to MSTestExtensions as my unit tests were not using it. Additionally, if I comment out the MSTestExtensions using statement, the inherit MSTestExtensionsTestFixture statement on the class, and the [TestTransaction] attribute, I don't have this problem. Adding the using statement back in doesn't cause the problem. Adding the [TestTransaction] attribute doesn't cause the problem. Once I inherit from MSTestExtensionsTestFixture on the test class, the issue presents itself.

Basically, the problem is that when I execute the following code in a situation that it will fail (such as the actualPartNumbers list containing two parts, whereas the expected list contains only one), the AssertionException goes unhandled by MSTest.

Assert.That(actualPartNumbers, Is.EquivalentTo(expectedPartNumbers));

Thus the IDE stops at the thrown exception, rather than fail the test. Sometimes this doesn't happen and the test will fail normally. But in most cases the IDE stops at the thrown exception. Any ideas?

FYI: I'm using MSTestExtensions so that I can do database rollbacks ([TestTransaction] attribute) after each test. This is similar to MbUnit's rollback feature. I'm overriding MSTest's asserts with NUnit's because I like the fluent style better. Lastly, I'm using MSTest because I'm having issues with NUnit. Particularly with Microsoft Moles and conflicts with third party references that use log4net. I'm trying my best to setup the unit/integration tests to be able to run in either framework in case I switch. But for now MSTest seems to be the least hassle and the integration in the IDE is very nice.

+1  A: 

Could it perhaps just be a matter of the key combination that you're using to initiate the tests: ctrl+R, ctrl+T vs ctrl+R, T?

http://stevesmithblog.com/blog/run-mstest-without-breaking-on-exceptions-in-vs2010/

Dave Falkner
Ctrl+R then T allows me to run the test just fine (as does running the test via right clicking in the test context on run tests), when otherwise it would stop at the exception. Cntrl+R+T does indeed stop at the exception. However, I'm also getting the problem when I set the test project as the startup project and press F5. I'd like to be able to run all tests at once, not one at a time. Is there a way to do a ctrl+R then t like operation on the entire test suite?
Matt Spinelli
Also Ctrl+R+T does not stop at the exception if I don't inherit from MSTestExtensionFixture. So this still looks like a MSTestExtension issue.
Matt Spinelli
Additionally, if I comment out the code that maps the Assert and Is object to NUnit (and thus use MSTest's Assert), then change the assert to Assert.Equals(1,2) and press Ctrl+R+T and F5, the problem still exists. So it's also doesn't appear to be an issue with using NUnit asserts as it also affect MSTest asserts. Again, if I don't inherit from MSTestExtension, I don't have this problem.
Matt Spinelli
I just realized that if I press Ctrl+R then T at the top of my code file (i.e. not within the class) I can run the entire test suite without this problem. Thanks for this workaround. I still would like to know why this is happening or have a fix. But thanks again. I didn't know about these shortcuts.
Matt Spinelli