The Death of NUnit Revisited: Will it be Fire?
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.
About NUnit 2.2.4... Whoops... Make that 2.2.5
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.
NUnit for .Net 2.0 - Do We Really Need It?
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...
When You Don't Have a Framework
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.
User Test Fixtures: How Many? How Long?
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.
What's a Test Worth?
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.
Test-First Challenge - Table Model
So we're evaluating expressions. Now we are to create a two-dimensional adapter for Sheet so cells can be referenced by row and column. Since this specific interface is aimed at a Java-based GUI, I'm not really sure if I need all of it. But I've put it together quickly using the tests Bill supplied.
Test-First Challenge - Cell References
Having built the parser in Part 2 and cleaned it up in my Refactoring Interlude, I'm now ready to handle references to cells in the formulas. First step is to have a new token type that handles "names". I made these be any span of alphanumerics starting with an alpha. This is actually a superset of the pattern called for in Bill's tests, but it can be changed later if necessary. Here's the new version of LexicalToken.
Test-First Challenge - Refactoring Interlude
In Part 2 I developed a parser that handles integer constants and some operators. In doing this, I built up some design debt and I now need to refactor. In addition, Part 3 now calls for formulas to handle references to other cells. This will call for some preliminary refactoring based on some quick design thinking. On this page I describe both refactorings and also discuss how I feel about all this change.
Test-First Challenge - Basic Formulas
Part 1 was originally done with only one string holding the content for all the cells. As expected, this broke on the first test of Part 2 (testManyCells) and some refactoring was required.