I used Resharper’s unit-test runner for the first time while spelunking WatiN last week and quickly became a fan. If unit-test runners were high school boys, here are a few reasons why the Resharper test runner would be dating the entire cheer leading squad while the NUnit test runner would have to bribe a distant, homely cousin in order to get a prom date.
- Integrated IDE experience: I think NUnit is good for deployment scenarios when you just want to load the test dll and verify the environment, but using a unit-test runner that is not integrated into the IDE is too frustrating for me when it comes to normal development. I used NUnit exclusively for several years, but I’ve been too spoiled by TestDriven.NET, SharpDevelop, and even MSTest to want to waste any more cycles switching between applications.
- Navigation between Tests and Code: Resharper lets you run tests by right-clicking anywhere in the test code (similar to TestDriven.NET) or by clicking on the ’gutter icons’ to the left of the code window. You can navigate in the other direction by simply double-clicking on the test icon, a feature I often use when investigating why tests fail.
- Ad-Hoc Test Groupings – The only way to organize groups of tests that can be run together in NUnit is through namespaces. This works fine for groupings that you could plan out ahead of time such as fast-running vs. slow-running tests or tests that share common dependencies. However, if you do have to run tests from different namespaces in the NUnit GUI, the only way to do it is to highlight and run one test at a time (you can’t even use the ctl-click option to highlight multiple tests). MSTest made a step in the right direction with their test list by allowing you to simply drag tests from different namespaces into a list, however Microsoft made the mistake of only including this feature in the Team Suite edition (which costs $10,000 plus an primary appendage) and also only allowing a test to belong to one list at a time. Resharper solves this issue by allowing you to add any test to a Test Session and also by implementing the Ctl-Clicking functionality to highlight multiple tests. There are also filter buttons on the toolbar that allow you to do things like only rerun the tests that failed.
- Test Validity Status Monitoring: If you have changed and rebuilt your code without rerunning your tests, little question marks appear over the red/yellow/green icons. Depending on the size of the project and your use of shortcut keys, rebuilding can become an automatic reflex like saving a document so it’s nice to get a smart reminder about whether or not your last test results are still valid.
Let me conclude with a disclaimer that I am primarily talking about the best way to run test written with the NUnit framework. When choosing between frameworks, I am now an advocate of MBUnit for reasons I’ll outline in a future post.
Popularity: 7% [?]