Stating the Obvious: Pre and 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 realized I’d said it all before… Requirements and Specifications.

Still, I think the message is worth repeating.

Back in the early 1990s, everything was better, the Cold War had ended, the world seemed to 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 for 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 set up 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 put 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, as 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. 

What does this prove?

Perhaps not a lot.

Or perhaps that TDD and BDD are the logical continuations of an old approach from the 1970s, at least. They have a longer lineage than is commonly recognized 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. Another programmer, Mark, and I 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.

Looking back on it now, 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.