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).
Comments
There are 4 comments on this post. Post yours →
A good assessment :) I myself only recently converted to BDD and am still trying to ramp up my speed with the ‘write spec, run test, fix code’ cycles (autotest really helps a lot).
Chu Yeow: I hear you on that front, I need to get some of the autotest stuff sorted out as well. I also stumbled across a Cruise Control (continuous integration) implementation in Ruby the other day (done by ThoughtWorks) which looked interesting. Might give that a whirl at some point as well.
NASA?
We can live with a little bit of test error on a measly utility package :p
http://oodt.jpl.nasa.gov/pds-utils/junit-report.html
To be fair, it’s probably just some external service unavailable during the time of the test. Surely they could’ve mocked that connection.
I’m just waiting for the day of XTFBDDD the holly grail of everything-driven-development.
Sorry Daniel, it has been a very slow day. :)
I agree with the graph you have there.
Having a decent amount of tests sure give the good feeling of “we’re not going to be screwed”. Though it’s not a 100% guarantee, e.g. from time to time we still need to debug things no matter how much tests we have.
I often see having tests as a defensive approach. But hey, defense wins championships :p (apology for the basketball specific reference, it might be totally different in hockey).
Post a comment
Required fields in bold.