Bacon Driven Coding

There’s been some scuttlebutt recently on the extreme programming mailing list about the value of YAGNI — You Aren’t Going to Need It. Apparently, some people have been interpreting it as “Don’t think about the future.” It’s supposed to be “Don’t build things today that you don’t need today.”

If you know that someday, down the road, you may have to support multiple platforms, It’s entirely reasonable to choose OpenGL over Direct3D — OpenGL will run on Windows, Macs, and X platforms, where Direct3D will only run on Windows.

Contrariwise, if you’re only releasing on Windows this version, there’s no reason to build that classic hierarchy of GenericWindowInterface—->MSWindowsInterface today. You Aren’t Going to Need it. When we do a Mac build, then we’ll add that.

Anyway, here’s my replacement analogy for YAGNI: We only need ten yards. (For those not familiar with American football, the team gets four chances to move the ball ten yards. When you have moved the ball ten yards, this process resets, and you get another four chances to move the ball ten yards. Eventually, you’ll make it over the goal line and score points, but that’s later; This play is to get ten yards. A yard is just slightly shorter than a meter.)

So when someone says, “We need to add extensibility hooks here in case we want to offer plugins later,” you can reply, “We only need ten yards.”

So, earlier I mentioned Mock Objects — The TDD variant that requires isolation of the tested component. The Mock Objects technique requires a hierarchy of tests:

1. At the lowest level, objects are tested in isolation against mocks.
2. Higher up, objects are tested in collaboration with a few other real objects.
3. Higher up, the entire system is tested.
4. At the top level, test define if the system is complete.

That’s a good hierarchy. My only problem is with the names that they use.

Mock Object developers use these names:

1. Unit
2. Integration
3. System
4. Acceptance

Long before that, I head people use these names:

1. “Why are you testing at such a low level? Don’t waste your time.”
2. Unit
3. “We probably ought to run the whole thing on some sample data.”
4. Acceptance

On top of which, there are two other things called “Integration Tests”, which long predate Mock Objects:

QA Integration Tests: We’ve upgraded to the latest version of of GUI library. Let’s run some integration tests to make sure nothing broke. (Usually a full regression sweep.)

(Pre-Agile) Developer Integration Tests: We’re merging three new feature branches on Tuesday. We’d better do some testing to make sure they integrate properly.

At this stage of the game, it’s just not a good idea to re-use existing terms for different things. Especially when telling the difference between those things requires you to read the mind of the speaker.

So I’ve been looking in at Test Driven Development more lately, and I’m trying to separate the several things that call themselves TDD. Here’s what I’ve got so far:

Classic TDD: as described in Kent Beck’s Test Driven Development by Example, this technique tests and writes code a a very low level. No line of code is written without a failing test. Design comes from refactoring to remove duplication.

Mock Objects: Steve Freeman and co. promote this version of TDD. Its distinguishing feature is a requirement for near-complete isolation of objects under test. Design happens during the writing of the test when new collaborators are discovered.

The Un-named TDD: Maybe we should call it “Test-First”. Medium size tests are written, often close to the level of a use case or scenario. Corner cases are usually not tested. (Disk is full, so you can’t write the file, etc…) Just enough testing is done to verify that the system works. Design is done via refactoring, but the decision of how to refactor is based on the developers taste, not just on removing duplication.

The Un-named TDD (with Mocks): Some people combine the convenient mock generation frameworks of Mock Objects with the unnamed TDD. However, they use them for conveniently removing parts of the app that are annoying to configure, not for isolating the system under test.

Presenter First: Maybe just a sub-species of Mock Objects, this strategy is notable for recommending that the application be built outside-in.

Behavior Driven Development: I know this is related, but I don’t know enough about it to say anything.

I used to do the unnamed TDD, and have only recently discovered that I wasn’t doing Classic TDD. I’ve been trying out Classic TDD, and it’s very intriguing. I learned TDD from a combination of Wiki, XP Explained, Refactoring, and XP Installed. (Sort of.) I wonder if those older sources don’t contain as good a description of it as the TDD book, or if I just missed it.