In my earlier post, The Death Of NUnit - Will it be Ice?, I adopted the notion - promoted in some mailing list posts - that NUnit might be dead or dying. I identified two big worries: death by ice and death by fire. Ice stood for frozen inactivity on the part of the project itself - failure to move ahead. Fire symbolized competitive forces, which might make NUnit obsolete.
I've been occupied with other things and not blogging lately. Meanwhile - in fact this is one of the things I've been occupied with - NUnit 2.2.4 was released. People tried it and found a few bugs - NUnit 2.2.5 corrects them.
The NUnit 2.2.3 release contains two versions of each download: one built with .Net 1.1, one with .Net 2.0. So, what's the deal? Do we need separate versions? And which version do you need? I'll try to explain...
We forget sometimes how easy it is to write tests - even without a framework. I was sitting in a cafe, working on my new laptop. It's an Acer Ferrari 4000 that I'm very happy with, but I haven't completely set it up yet.
There's a discussion going on right now on the Yahoo Test-Driven Development list regarding the use of a single instance of the user TestFixture class in NUnit 2.x, as compared to multiple instances in NUnit 1.x and in JUnit before it. A related issue, discussed on the same list a while back, is the question of the lifetime of that single instance. Here's my take on how the issues relate and how NUnit deals with them.
In a discussion about unit-test suites that take too long to run, Ron Jeffries writes
Splitting the tests into slow and fast is a tradeoff, and it's an easy one. But is it ideal? I think not. I think a better approach might be to split the tests into "likely to provide interesting information" and "unlikely to do so". Then make the ones that are likely, also fast.
This struck me as an interesting point. If the value of a test is seen as the amount of information it is likely to provide and the cost is - at least in part - the time to run it, then the problem of which tests to keep in that "too slow" test run is quite similar to the value versus cost balancing problem we face in XP when we schedule stories into an iteration.