The Zen of Unit Testing
Filed Under Quality Controls
The pupil asked the master programmer:
“When can I stop writing tests?”
The master answered:
“When you stop writing code.”
The pupil asked:
“When do I stop writing code?”
The master answered:
“When you become a manager.”
The pupil trembled and asked:
“When do I become a manager?”
The master answered:
“When you stop writing tests.”
The pupil rushed to write some tests.
If the code deserves to be written, it deserves to have tests.
More great zen testing lessons can be found in The Way of Testivus by Alberto Savoia
Comments
3 Responses to “The Zen of Unit Testing”
“People who don’t want to test, write tests. Its the con-artists way to avoid work and have something to show for it.” “Unit tests are like police road blocks – they only catch the stupid while the incideous walk right by.”
@Zen –
“Be careful when opposing testing. Nothing has ever been proven without being tested for correctness.”
It is fun to see intelligent words of someone in opposition. Unfortunately, I view these words as coming from someone who has wasted time creating worthless unit tests (such as getter/setter testing) and has never had the opportunity to be mentored in creating great unit tests.
Either that or the most intelligent flamebait I have ever seen…
@Zen – are you playing devil’s advocate or what?
Yes, I write unit tests because I don’t want to test manually. I prefer to write code which can be tested directly, instead of having to fire up the UI and push all of those buttons. This also makes the code more OO and easier to understand. This is not just my opinion or dogma. My peers have confirmed this.
Most of the bugs, trivial or serious, I’ve encountered are “stupid” coding mistakes. They could have been found if the author (including me) had take the time to write unit tests up front.
The really “incideous” bugs usually pop up from some nasty piece of code that I call “stream of consciousness” functions. You sit down, you have everything in your head the code needs to do and you just start coding. It made sense at the time, but once that thought slips from your brain, you have no idea what the code does.
This kind of code usually doesn’t have unit tests because the developer just blasted it out non-stop. And every time someone new looks at it, they decide that it will take 2 days to understand the code and write unit tests, or just 2 hours to kinda understand the code and make a change that you THINK won’t break any thing.
And yes, most of my points are not absolutes. It is possible to write a unit test for code that is not OO. And one can write OO code without writing unit tests. It is also possible to write unit tests for a transaction script that is 700 lines of code. And I suppose it is possible to write a huge transaction script which clear and elegant, but I’ve never seen it.