I have to admit that I very little experience with other unit testing frameworks. I’ve never felt the urge to switch because NUnit has served me so well over the years. NUnit is simple, effective and does not create additional friction. NUnit does take some flack for not having changed much over the years, but I think that is a strength because it hasn’t had to.
Recently I took the plunge into MSTest. I hadn’t heard many good reviews, but from the outside it looked “the same”. I mean, all I need to do is replace [TestFixture] with [TestClass] and [Test] with [TestMethod] and it would all work, right? Wrong. I was about to post “Why I Hate MSTest” but in the interest of staying positive, I’m posting “Why I Love NUnit” instead.
NUnit stays out of the way. It does not impose any structure on the project structure I choose. I can choose to put test classes in the same assembly as the classes they test, or I can choose to put test classes in a separate assembly.
Asserts just work. This is especially evident when comparing collections. I can compare collections of different types, it doesn’t matter if it is a Collection<T>, an IEnumerable<T> or an IList, NUnit is smart enough to compare each of the items in each collection. I had not even thought of this until I switched frameworks and it didn’t work.
When a test fails, NUnit tells me why the test failed with a very descriptive message. This is extremely important because I want to maintain the short cycle rhythm of TDD. Some frameworks rely more on providing links to the code that failed rather than providing a helpful message, but when running tests from the command line or with TestDriven.NET I can only rely on the error message.
TDD is a practice that strives to create a constant rhythm for the developer in order to maintain constant progress. NUnit is a framework that just stays out of the way and allows the developer to maintain that rhythm without fuss or interruption. Simple, concise, effective. What else would I want?
No comments:
Post a Comment