Posted on

Test Driven Development in Microsoft .NET: A Review

I finally finished reading Test Driven Development in Microsoft .NET by James Newkirk and Alexei Vorontsov, both of whom contribute to NUnit development. [1] I’m still very new to the ideas of Test Driven Development (TDD), this book being my first “formal“ look into it.

Essentially, TDD is about writing the tests first, before any of the actual code is written, so that you think about how the code is used rather than how the code is implemented: because I read blogs like Brad Abrams and Steven Clarke, I think the former is far more important. So the basic flow for TDD is the following:

  1. write a test case;
  2. compile;
  3. get compiler errors;
  4. implement just enough of the class under test to compile;
  5. run the test, get red;
  6. implement just enough of the code to pass the test;
  7. run the test, get green;
  8. refactor to remove duplication;
  9. repeat

That’s a few more steps than “Red/Green/Refactor,“ that they often quote in the book (I don’t have the book with me(what?!?), but I believe Kent Beck is the source for that saying), but that’s what they were doing in the examples.

Why finally?

You might have noticed the “finally“ in italics at the beginning of the post. The first four chapters I read in a day, the last six, in which they develop an album database web service app, took three weeks (maybe longer). It might be that I’m so new to TDD only an introduction and a good example (they did a Stack), was all I needed to get going. Or it may be that, since I don’t do web service development as my day job, that I just didn’t find the final six chapters all that appealing. My eyes tend to glaze over when there is a lot of code on the page and there is a lot of code on those pages.

That’s not to say that the book is bad, far from it. I learned a lot from the whole book, the first few chapters especially. Before the book, I had used NUnit to create tests, but they wouldn’t provide the coverage for the whole class. Often my classes would go without unit tests because I’d be in one of those “zones“ where I write out all the code I need to do whatever. Then, when it’s over, I’d start thinking of unit tests, but the task would be so daunting that I’d just forgo the whole unit test writing. I’d create countless console apps and hang out in the debugger, like I was “taught“ in university. Now that I’ve read this book, I still do that, but to a much lesser degree. I don’t quite have the discipline to perform all those steps in order, but I’m getting better. Sometimes a test will come way later than the code. Sometimes, I’ll get ahead of myself with all the tests I write. But essentially I follow the above steps pretty closely.

Since reading the book, I’m way more confident in the code that I write, I spend significantly less time in the debugger and I don’t write a lot of extra, thow-away driver apps for my libraries. I’ve been trying to do TDD now since that first day with the book, and I’ve found some places in .NET that the book falls short in. Considering the book’s title, I’d expect to see something on testing events: nope, nothing. Testing attributes? Nope. (Admittedly, I don’t see how testing a custom attribute is any different than testing a class, but still…) I would have liked to see something on the stuff that makes .NET a little different than the rest like delegates, events, etc. There was also no mention of mock objects, testing winform apps or testing ASP.NET apps, other than saying it’s hard to really do it. Nevertheless, I think this book is a good start for TDD in .NET.

Before writing this review I thought I’d check out Google on some of the questions I had, but it let me down. However I did find this link extravaganza on TDD in .NET on Darrell Norton’s weblog. I haven’t really gone through it thoroughly, but it looks like a good starting point.

Recommended if… you’re about to graduate or have just graduated with a CS degree and like .NET, you’re new to TDD and develop .NET, or you’re a complete nerd like I am.

[1] James Newkirk is the lead developer of NUnit.

Posted on

The Confusion – A Review

The problem with a book of great length is that you’ve spent so much time with it, once it’s over, you miss the characters and want to know what happens next. I have just finished reading The Confusion by Neal Stephenson. I was a little unsure about Quicksilver, the first book in the trilogy: I was led to believe that this trilogy was to be about the feud over the invention of the calculus. I happen to find the history of mathematics very interesting on its own, so when I started Quicksilver that’s what I was expecting. And after Cryptonomicon I was expecting something in that vain, only with all the trappings of late seventeenth century. What I’m hinting at here is that I was a little disappointed with the first book.

Now that I have just finished The Confusion, I think I have to re-evaluate Quicksilver. I now see that Stephenson is writing about the Newton/Liebniz controversy, but that to write solely about it would be to ignore a much larger, and more interesting, tale, the Scientific Revolution. I have read all Stephenson’s major works, and I suppose I should have had more faith in his storytelling. The Confusion has all the stuff you’d expect from a Stephenson novel: great characters; a sprawling, ambitious plot that he patiently unfolds; and the always enjoyable diversions to explain whatever he wishes. Admittedly, the diversions in the first two-thirds of the Baroque cycle aren’t nearly as entertaining as in Cryptonomicon. Nevertheless, the exploits of Eliza and, of course, Jack Shaftoe have held my rapt attention for last few weeks.

If you have read any of Stephenson’s previous works, or are interested in the period (1660 – 1713), I recommend the Baroque cycle (of which, Quicksilver and The Confusion are the first two parts). If you are involved at all with computers, you have to read Cryptonomicon

Now I need only muster the patience for October and the final installment….