I got some interesting comments on my previous article about unit testing Maatkit, including echoes of my own conversion to the unit-testing religion. One of the objections I’ve heard a lot about unit-testing is how it’s impossible to test code that talks to a database. “It’s too hard,” they say. “Oh, it’s easy to test a module that calculates a square root, but a database? Way too much work!”

Note: As commenters have pointed out, I’m not necessarily using “unit” in the agreed-upon way here. Everything I say can be applied to ultra-pure unit testing too, but I go beyond that. I will hold fast to my assertions about mocking though *grin*

Is it really impossible or even hard?

I disagree. In one of my previous articles I said …

Over in Maatkit-land, Daniel Nichter and I practice test-first programming, AKA test-driven development. That is, we write tests for each new feature or to catch regressions on each bug we fix. And — this is crucial — we write the tests before we write the code.* The tests should initially fail, which is a validation that the new code actually works and the tests actually verify this. If we don’t first write a failing testcase, then our code lacks a very important guarantee: “if you break this code, then the test case will tell you so.” (A test that doesn’t fail when the code fails isn’t worth writing.)

Most of the time when I do this, I write a test, it fails because I haven’t written any code yet, and I then go do some kind of …

As you probably know, I recently finished writing a book with a few co-authors. I kept notes along the way and wanted to describe the process for those who are thinking about writing a book, too.

Update: see the followup post for more of the story, including my editor’s responses.

I think it’s important to be objective; my purpose here is to help prospective authors get a feeling of what it’s like, and it’s not all good (but I’d encourage people to do it anyway). Hopefully I won’t come off as sounding peeved at anyone or like I’m trying to put people down. I’ll have a lot to say about what went right and wrong, and how it helped and hindered the process.

Please excuse the rambling nature of this post. I’d love to …