Stating the obvious: Pre & Post conditions and TDD

Can you have an epiphany more than once?

Well I did. In early January - perhaps the result of all the Christmas drink - I had an epiphany and wrote this blog post. As I finished writing the post I realised I’d said it all before… Something old, Something new:

Requirements and Specifications.

Still, I think the message is worth repeating…

Back in the early 1990’s everything was better, the Cold War had ended, the world seem be fighting just wars, I was having fun at University and my lectures were convinced that formal methods - logic based VDM-SL to be specific - were the silver bullet to software development. And so I spent three years being schooled to write pre and post-conditions on every function I wrote.

Actually, this made sense to me at the time and I continued it long into my professional career. I still find it useful to think like this although I long ago gave up actually writing them as comments. That was one of the failings, if you just wrote them as comments then they aren’t enforceable and they can easily become another piece of documentation which doesn’t match the code.

An improvement to this, and the way I used to write a lot of C++ code was to use assert. So my code would look something like this:

std::list<std::string>

extract_reviewers(std::map<std::string, int> *votes_cast) {

        // pre

        assert(votes_cast != null)

        assert(!votes_cast.is_empty())

        …

This was an improvement but you needed to execute the code to make it happen. And that meant powering up the whole system.

So today I’m writing some Python, and my app just crashed, and I looked at the code and its obvious that the function in question shouldn’t have been called. “Arh… there is a test I missed somewhere…”

And it dawned on me… probably again…

When I write a test for a function I’m writing executable pre and post conditions. Here is the code:

self.assertEquals(dedupvotes.retrieve_duplicate_report(self.c.key), None)report = dedupvotes.generate_duplicate_vote_report(self.c.key, 1)self.assertFalse(report.has_duplicates())voterecord.cast_new_vote(submission_keys[1], "Allan", 1, "One", VotingRound)voterecord.cast_new_vote(submission_keys[1], "Grisha", 2, "Two", VotingRound)self.assertFalse(report.has_duplicates())voterecord.cast_new_vote(submission_keys[1], "Allan", 1, "One", VotingRound)self.assertTrue(report.has_duplicates())

See?

In the test setup I setup the pre-conditions. I may even test them.

I call the function, generate_duplicate_vote_report, and I check what happens, the post conditions.

(OK, it is not the most polished code, the refactor step has yet to happen.)

What has happened here is that I’ve moved the policing of the pre and post conditions outside the function. In VDM the pre and posts were comments wrapped around some imaginary code. In C++ the asserts top-and-tailed the method, with TDD the pre-and-post it in a special function. And the test harness allows just that code to be tested.

I was always taught to write the pre and post conditions first. Indeed, in VDM there was no actual code so you could only write the pre and post conditions. In other words: I was writing the tests before the code.

And now I write this, I remember I have made the same point before. When I made this point before I was discussing TDD’s younger, but possibly wiser, brother, BDD. If you want to have a read it is Something old, Something new:

Requirements and Specifications. That essay is also included as an appendix to Little Book of Requirements and User Stories.

What does this prove?

Perhaps not a lot.

Or perhaps that TDD and BDD are the logical continuation of an old, 1970’s at least, approach. They have a longer lineage than is commonly recognised and that in turn increases their credibility.

It also reminds me of 1994 when I was working in the dungeon of a small company in Fulham. Myself and another programmer, Mark, were racing to deliver a C++ system to a client and save the company. We were writing test harnesses for our code and I was writing pre and post conditions. In retrospect his tests were better than mine, mine often needed a human key-press, I think his might have been added to the build to.

In retrospect too, we came perilously close to Test Driven Development but we didn’t think it was anything very special, we didn’t name it, we didn’t codify it and neither of use made much money out of it.