Yes. More on testing, and probably nothing new or revolutionary either. As I’m attempting to write tests, fix stuff, and sort out some fun multi-byte character issues, I’ve realized again at how much better it is to be on a project once you reach the state of being proactive, instead of being reactive.

The problem with reactive bug-fixes/features/HOLYCRAPTHISNEEDSTOBEFIXEDRIGHTNOW/etc. is that if your codebase has any sort of, say, complex business logic – it’s likely that reactively doing updates in this fashion is going to come and bite you in the back side.

Being able to proactively perform these updates is a state that I think applies if you have enough unit tests, functional tests, integration tests, and maybe even regression tests in order to ascertain that the new code that you’ve written doesn’t wreck anything currently deployed, and with any luck, you’ve also written some new tests that test the new code that you’re deploying. Go figure (I told you that I didn’t have anything new or revolutionary that I wanted to say).

I spent a bit of time trying to elaborate this relationship in a pretty picture – and here it is:

Basically, the less tests you have, the more reactive you are, and the more screwed you are. The more tests you have, the more proactive you are and the less screwed you are. This is what I shall now refer to as the Triangle of Happiness (the green one).

It’s also worth noting that the # of tests (this doesn’t necessarily mean # of tests, but could be code coverage, whatever) – is decidedly NOT a linear relationship with proactivity. Writing tests definitely reaches a law of diminishing returns. As your screwed-factor (reactivity) approaches zero, and your proactivity-factor approaches infinity – the number of tests that you have to write in order to further increase your proactivity-factor is exponential (give or take).

So, tests are crucially important so you don’t get screwed, but 100% code coverage is absolutely not cost-effective and (in my opinion) not necessary (unless maybe you’re NASA, or people die when your software sends an order of Cookies to Canada instead of California).

Right now, I’m finding it quite ironic that I’d been thinking about this all day yesterday, after trying to retroactively write some tests for a project that I came into rather late in the lifecycle.

Cedric just posted an entry with the exact same title, almost as if to taunt me with his infinite testing wisdom.

At about 200 times during the day yesterday, I came across a piece of code and thought to myself:

“How in the &$^%#@! am I going to write a test for this?!?”

So with any luck, Cedric will be able to get Hani to stop biling and whining about XML – and finish their testing book so I can go buy a copy.

In the meantime, it seems like the new question I am going to ask myself when designing a piece of code is something along the lines of:

“Sure, this design is elegant, but is it testable?”.

And as Cedric mentions, writing testable code is not necessarily writing code that is better designed.