In my last blog post, there was a bit of a discussion in the comments about whether data in unit tests should be hardcoded or not.  Tom Metro scored the last point with this comment:

We always coach developers to use hard coded test data to the extent practical. When writing tests you have to unlearn a lot of DRY principles. We tolerate a lot more repetition, and factor it out sparingly.

and then I said that this really required a longer discussion than blog post comments would allow.  This, then, is that longer discussion.

So, first of all, let me agree whole-heartedly with Tom’s final statement there: “We tolerate a lot more repetition, and factor it out sparingly.” Absolutely good advice.  The only problem is that, as I noted previously on my Other Blog, we humans have a tendency to want to simplify things in general, and rules and “best practices” in particular.  I don’t think that Tom was saying “always hardcode everything in your unit tests!” ... but I think some people will read it that way nonetheless.  I would like to make the argument that this is a more nuanced topic, and hopefully present some reasons why you want to consider this question very carefully.¹

I happen to be a TDD proponent.  Now, right there I’ve probably lost about half of you, and the rest are probably going, “okay, yeah, get on with it.” TDD is one of those things that people either love or hate.  For a full meditation on the ins and outs of technical hype, I’ll refer you to my other blog.  In the meantime, if you’re one of those people whose sneer at the thought of TDD is still stuck to your face, I’ll ask you to indulge me for a few more paragraphs (two of which are only one sentence long).  After that, if you still feel like TDD is the stinkiest thing to come along since Pepé Le Pew, you can either jump over to the link above, or just continue on, mentally subsituting “TDD” with some technical process you actually like.  Or, you know, find something else to do entirely.

My first experience with TDD was via XP (that is, Extreme Programming, not the horrid Windows version), specifically the original book by Kent Beck, where it’s referred to as “test-first programming.” Like many of the ideas therein, test-first programming was completely insane.  I knew instinctively that it could never work.  So I immediately decided to try it.  Why?  Probably because I often find myself in the position of telling other people about insane ideas that they’re positive can’t possibly work, and hypocrisy is one of my pet peeves.  So I decided to pick a project (not a paid one; one that I was working on on the side) and use test-first programming at least until I reached my first milestone.  And, let me tell you: I hated it.  Utterly despised it.

For about two or three weeks.

Then, all of a sudden, the lightbulb went on.  Just like it had when I suffered through learning vi for the first time.  Just like it did about halfway through my first project using version control (RCS, it was, back in those days).  Just like it did when I finally grokked spreadsheets using Lotus 1-2-3, or (as I mention in the other blog post) OOP while learning C++.  And now I use TDD a lot, and I evangelize it to my co-workers.  It really has changed the way I program.