My not-so-humble evaluation of VS tests distinctions from NUnit is (in points on -10 to 10 scale).
- (-4) To run tests, VS launches an entire process which takes no less then 3 seconds to start. If you’re in “F5 hit breakpoint – Shift-F5” loop, that’s disgusting. NUnit tests can be run in-process by Resharper or TestDriver.NET;
- (-2) GUI that shows where test failed is ugly. You don’t get to failed line on double-click, you first get to test log page. Status and call stack are necessary, but I’d like not to trash my document tabs, I already have enough of them open. You can’t make that kind of windows docked/floating;
- (-1) You got a “
public TestContext TestContext;” sticking in your code. You’ll need it only when it comes to testing on data, which doesn’t always happen, even in a data-driven application; - (-1) It’s a “not invented here” technology, while NUnit was around for years;
Edit: In a moment of madness, I mixed together coverage profiling and unit testing tools. May God and readers forgive my aberration.
Edit2: If you need a half-page kickstart in unit testing techniques, the next post can help.
2 Comments
(+5) it’s supported by microsoft
(+5) they can be run by anyone with VS2008, no external dependencies
That “supported” is a word people fall under magic of.
Effectively this means that “some issues have a chance to be resolved in the next release in one or two years”.
We had quite a big issues with TFS, and that is what happened.
For NUnit, you have ways greater chance of someone resolving your issue in time, if not yourself.
So, I’d say: (-4) NUnit is opensource and has a good community support.
For second item, it’s also arguable. To turn VS into a good IDE, I demand ReSharper.
Which supports NUnit ways better then VS does for VS.Test.
Which brings us back to “(-2) GUI that shows where test failed is ugly”
Post a Comment