Just had an interesting conversation with a couple of colleagues about why I'm trying to get interoperability in my tests between MSTest and NUnit. I thought I'd covered this in an earlier post, but if not here's another summary.
The current implementation of MSTest inside of Visual Studio doesn't seem to fit (at least my interpretation of) how Test Driven Development should fit into your daily development cycle. Developing with unit tests needs to have a constant rhythm of code, test, code, test. Ideally the test part should be transparent, at least not seriously interrupting the flow of your coding. MSTest fails on this front as far as I'm concerned, things that are missing are:
- When I rebuild my test assembly - rerun the last set of tests I ran
- When you run my tests, do it out of the way - I don't want to know that you've run them until you find something that fails
- If I've built my tests to run fast (as they should), I want you to run them fast
However, MSTest wins hands down over all other testing tools thanks to its' TFS integration. The publishing of results back into TFS and subsequent analysis in the datacube for results and code coverage is just superb.
This leaves me with a difficult problem - I want to use something like NUnit whilst coding, but also to use MSTest whilst building centrally. Hence why I'm trying to have my cake and eat it with the dual test framework idea.
I've not had the opportunity to use it on anything of any scale or importance yet, but I've confirmed the theory with a few simple projects I've got running in my home TFS Server. The NUnit GUI sits quietly in the background whilst I code, monitoring changes to the test assemblies, happily re-running the tests when its rebuilt, only making itself known when there's a failure. My TeamBuilds then switch over to running MSTest and I get the flow of data back into TFS that I was expecting.
As I get to use this pattern more often I'll keep you all updated on my progress (fingers crossed I can keep using it).