Abstract
Although the title might allude to a phrase in the newest Star Wars movie, the context of this article is more serious. First of all, it is good that people read books. However, they need to be interpreted correctly. How often aren’t design patterns misused for the fun of it? This blog article is about another aspect which made its revival with test driven design (TDD) and extreme programming (XP). This article will focus on the ‘danger’ that lies in the unmanaged use of assertions.

1 INTRODUCTION
Assertions are contracts, just as Bertrand Meyer already stated several years ago. A lot has been written already on assertions: from assertion styleguides to aspect-oriented frameworks for managing preconditions.

One of the base principles of contracts – in real life as well as in software – is the fact that it cannot be modified uni-lateraly.

For software, this implies that you cannot make your pre-conditions of your interface methods more strict all of a sudden when releasing a new version of a component.

Therefore, make sure to think upfront: The better you have thought everything through, the less contract re-negociations you will have to make in the future.
In this article, I’m using a real-life example to demonstrate the seriousness of what is – at first sight – an implementation detail.

2 A REAL-LIFE EXAMPLE

A general component which provides the implementation of a crosscutting concern is updated with extra precondition checks. Why? With the best intentions, the author of the component suddenly realised that he had forgotten to check some preconditions.

Without any further communication, the component is adapted and gets released. Of course, with the extreme programming thought in mind he also makes sure that all of his unit test work well.

Having received a new version of the software – which was just a ‘maintenance’ release by the way –, one of the applications which uses this component tries to integrate it. The integration goes seamlessly, as at first sight no ‘breaking’ changes have been made.

This is where the catch lies: In case an interface method would have been modified ‘by accident’, this would have been detected at compile-time when integrating. Integration would then be stopped prior to give an official ‘go’.

The people working on the application can run their unit tests and they – most likely – will just run. When they’re lucky the tests will fail on the extra precondition check. In a data driven environment, chances are low.

So when does this extra assertion pop up?
Of course, Murphy’s law pops up here: you can be sure of it that it will pop up at the least convenient time. As the problem can only be detected at run-time and nobody is really aware of this extra precondition it will escape the attention of both the development and QA department.

In a worst case scenario, you will see it at the customer site (when you are writing customer software), when you are giving a demo, etc. And this costs!

3 CONCLUSION
Use assertions wisely; go back to the essence of design by contract and treat every change to an assertion as a change to the contract. Secondly, make sure that your ‘contract’ is properly documented and that everybody that is involved is up to date.

REFERENCES
[Meyer88] Bertrand Meyer: “Object-Oriented Software Construction”, Prentice Hall, 1988.

About the author
Mario Van Damme is a software architect, working for quite a number of years in the medical industry, and prior to that in the insurance and banking industry.
He can be contacted by e-mail at: mvandamme@sopragroup.com [1] and mario.vandamme.mv@belgacom.net [2].