This post originated from an RSS feed registered with Agile Buzz by Laurent Bossavit. Original Post: Assertions (part I) 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)

Assertions are portions of program text which characterize some boolean expression that is supposed to be true at the point in the program where they appear.

Assertions help find and prevent bugs. Consider the two main ways that programs grow from simple to complex, from small to large: writing new code and modifying existing code. Assertions can be useful in writing new code, but they are crucial when modifying code.

When you modify code, the first thing you want is usually to figure out what the old code does. At the smallest level of detail, this often means looking at a variable and figuring out what values it can hold. Say we're looking at a chunk of code and we know count is an integer. If it appears within a loop, can we figure out whether it goes up or down ? Can we figure out if it will never go over a certain maximum ? If it's a parameter, can we rely on it to be positive ? Could we overflow if we use it in a multiplication ?

Being able to make confident statements in answer to questions like these makes modifying code easier and safer, because typically we can chain such statements together into deductions that end, "and so adding this line will result in correctly computing what is now expected of this function". Or, when looking for bugs, deductions that end, "and that is why the server keels over whenever one user logs in just after another has completed form Z".

Assertions arise in different "methods" for constructing programs - I use the term loosely. One of these is called Design by Contract, and there must be quite a few programmers who associate assertions with DbC. They're also used to construct loops.

Programmers familiar with Test-Driven Development who learn about assertions can have a sense of déjà vu, because the kind of tests that TDD popularizes have a similar role - they help reason about what bits of program do, by providing examples of the sort "when I pass this kind of input to that method, I get back that kind of result".

There are interesting questions which arise when comparing TDD-style unit tests and assertions; technical questions, to start with, but also questions which seem to go a lot deeper, when we ask what kind of things, logically, expressions are, compared to the rest of the program.

More later - stay tuned.