Last Updated: February 23, 2020
·
1.464K
· acgessler

Why assertions are so powerful

Most programming toolchains offer them. For some it is a library function just like any other (such as for C++ or C#), other integrate it into their syntax (Python, Java). I am arguing in favour of a programming style that makes heavy use of assertions (or more powerful tools, but this is not the topic for now).

Assertions are

  • to make your code safe by expressing assumptions. Let's say you call an API whose return value is an object that can, according to documentation, not be null. If you assert this to be the case, you don't have to worry about it again. In case the API does not conform to its own documentation (or you misread it), the assertion will fire. Safeguarding your own assumptions about the functioning of your own and of other people's code helps catch errors that would otherwise be terrible to hunt down. And things being null or not is just the easiest example of such a check.

  • to document your code. Assume a programming language that does not have object references that cannot be null. If you have an object reference of which you know that it cannot be null if the rest of the code is bug-free, you should assert such object reference to be non-null. By doing so, you can express this invariant more concise than you could with inline documentation, and you get a runtime check on it for free.

  • a way to clearly distinguish programming error from runtime error. A network port not being available is a runtime error. However, an API called with an invalid parameter is a programming error, which should (in an ideal world) not need any runtime checking at all because it is never relied on for the program's control flow! Java, for example, is particularly bad at this. raising (unchecked) runtime exceptions for invalid arguments is commonly part of the contract of a method and the checking can therefore technically not be omitted. What is caught by this construction at runtime is usually a programming error, one whose presence indicates a bug in the software. Assertions make this very clear. If you fail an assertion, you are not going to get around this except by fixing your code.

The prime reason for bugs in computer software is mismatch between your assumptions on how something will behave, and how it actually behaves. So if you carefully separate your own assumptions on the functioning of systems from actual runtime errors and learn how to write down your assumptions while coding - through the use of assertions - you might get more reliable software. A good sign is if during testing you only rarely get crashes within your code, but end up in your own assertions instead.

2 Responses
Add your response

Is not TDD intended to replace assertions?

Thanks for explaining though as assertions might help much in languages with which TDD is not so easily used, for example, complex shell scripts.

over 1 year ago ·

Well, TDD could be seen as a more sophisticated way of expressing your assumptions on your code. I use both and I think they play very well together.

Assertions can express very small assumptions that you cannot reach so easily by tests. To me it is more of a local tool that is great at making code another slight pinch more reliable, wheras TDD is maybe the big paradigm that supersedes the idea.

over 1 year ago ·