This post originated from an RSS feed registered with Agile Buzz by Laurent Bossavit. Original Post: Assertions have no behaviour Feed Title: Incipient(thoughts) Feed URL: http://bossavit.com/thoughts/index.rdf Feed Description: You're in a maze of twisty little decisions, all alike. You're in a maze of twisty little decisions, all different. Latest Agile Buzz Posts Latest Agile Buzz Posts by Laurent Bossavit Latest Posts From Incipient(thoughts)

Are the assertions used in Test-Driven Development the same kind of assertions used in Design by Contract ?

In DbC, two important categories of assertions are preconditions, which express what must be the case before calling a method, and post-conditions, which express what will be the case on returning from a method. Many TDD assertions are also claims about what is the case on returning from a method.

When discussing the two approaches, something I've often heard people ask about, or suggest doing, is writing a test to check that a method will throw an exception if its preconditions are not met. If we don't specify it, and therefore have a test for it, something bad might happen as a result of a failed precondition.

That's the wrong way around ! Rather, a failed precondition is the result of something bad happening. By definition, a failing precondition means that there is a bug in the caller.

Since the bug is in the caller, it is useless to do anything about it in the method that is being called. A method can have any behaviour at all when its preconditions are not met, and that behaviour will be correct by definition.

Using TDD to test for behaviour that cannot be incorrect is a waste of time, and ignores the rules of TDD ("test anything that can possibly break" implies "don't bother testing what cannot break").

I am claiming that wanting to test the behaviour of assertions is a sign of confusion. (I often use the phrase "assertions have no behaviour".) I'm leaving open, of course, the possibility that I'm the one who's confused. But if I'm not, then that confusion about the behaviour of assertions seems somewhat widespread; I encounter it regularly.

I suspect that the problem comes from not drawing a distinction between a program's "accidental" behaviour and its "essential" behaviour. I'm not too happy with the terms, which have a Platonic ring to them, but they're the best I can manage at the moment.

A program's essential behaviours are those that are described transparently by the text of the program. A program's accidental behaviours are those that arise from a particular implementation, or from a particular execution of a particular implementation.

The distinction is important: programmer often introduce defects by relying on accidental properties of their programs. I'll make up an example for illustration. (A "real life" example would be better; I'd be grateful to anyone who sends in suggestions.) Consider a method which takes as input an array and returns the number of unique elements in the array. Suppose that the implementation uses an instance variable to hold a temporary array element, and it so happens that the variable holds the first array element on return from the method.

Counting unique elements is essential behaviour, but providing a way to access the first element is accidental. If we write code that calls the counting method, but then add further code that relies on finding the first element in the variable, chances are that some modification to the implementation, down the road, will remove that property of the counting method.

I haven't answered the question I started with, the following might be a part of the answer: assertions (in both TDD and DbC) document essential behaviour.