CSC/ECE 517 Fall 2010/ch6 6b AK

Support for Assertions in Various O-O Programming Languages

Topic :Compare the support for assertions in various o-o programming languages. How well is it integrated with the language (instead of being supplied by libraries)? How many kinds of assertions are supported? How are assertions used in the various flavors of xUnit testing frameworks?

Introduction

Definition

An assertion is a boolean expression that checks the proper state of the program, methods invocation, change in state of data in the class, error handling and the method code for computation. Assertions are essentially a way to implement testing in computer programming and are specified by the programmer to check for correctness in a program. Assertions are a systematic way to check that the internal state of a program is as the programmer expected, with the goal of catching bugs. In particular, they are good for catching false assumptions that were made while writing the code.

Example

As stated above Assertions are boolean expressions and returns a boolean value, if its false, indicates a bug in the code. It prevents the flow of control to fall into an invalid state which would otherwise can cause serious failures.

/* Defining a object link of type List */
List link;

/* Asserting that the link is not null */
Assert link != null;

In the above example the second statement asserts that link is null. If it is then it throws a AssertionError. In a way, if any line after the assert statement is executed then it can assume that link is not null. In the remaining sections, we compare different OO languages and analyze the support of assertion in the languages.

Usage

• Design by Contract: Assertions may be specified at the class level or on the method level (preconditions and postconditions). A class level assertions, a condition that must not be violated by any method of a class. A precondition is associated with a particular method and imposes a correctness condition on the client or the entity using the particular method: i.e., the client must ensure that the precondition is fulfilled; otherwise the method is not executed. A postcondition is also associated with a particular method, but it imposes a correctness condition on the implementation of the method; a violation of a postcondition indicates an error in the implementation of the method.
• Runtime checking: Assertions that are a part of the implementation and can be checked at run time for correctness.
• Development Cycle: During the development cycle, assertions are used as a powerful debugging tool as part of unit testing the code.
• Static assertions: Assertions that are checked at compile time are called static assertions.[1]

Support for assertions in various o-o programming languages

Depending on the programming language, assertions can either be a part of the design process or they could be statements which are checked at runtime. In this page we are trying to research the support for assertions present in various o-o programming languages. The research is based on two main criteria:

1. How well the support for assertions is integrated with the language

There are several ways in which assertions are supported in different languages. Listed below are few strategies for providing this support.

• Built-in support: This means that support is directly included in the programming language. The programming language contains language constructs to formulate assertions in one way or another. The syntactical correctness of assertions is checked directly by the compiler. In addition a runtime environment must be available to perform the runtime assertion checks and also should be able to selectively enable and disable assertion checking.
• Preprocessing: The general idea here is to formulate assertions separate from the program or to include the assertions as comments. A preprocessor is used to weave the assertions into the program or to transform the comments containing assertion formulas into programming language code. The main advantage of this approach is the separation of programming logic and contracts. This is important in cases, where the programming language itself does not support assertions and the programming language must not be altered. The main disadvantage of this approach is that the original program code is changed by the preprocessor, i.e., line numbers of compiler errors do not actually fit the line numbers of the program. The same problem arises with debugging or runtime exceptions.
• Metaprogramming: According to Templ metaprogramming refers to “programming at the level of program interpretation, or in other words, to extending the interpreter of a given programming language in an application-specific way. Traditionally, this concept is available only in dynamically typed and interpreted languages” [2].

2. How many different kinds of assertions the language supports

There are different kinds of assertions that can be implemented. A few of them have been listed below.

• Basic assertions: Annotations in the implementation of a method.
• Preconditions and Postconditions
• Invariants

References

• [1] Wikipedia Page Assertions
• [2] Templ J.: Metaprogramming in Oberon, ETH Dissertation No. 10655, Zurich, 1994
• [3] Sun Microsystems: Java Assertion Facility

External Links

• Assertions in Python
• Assert statement in Python
• Unit Testing in Ruby
• Assertions in Ruby
• Design by Contract in Eiffel
• Design by Contract
• More information on Ruby Unit Testing
• Assertions in C++
• JUnit
• Unit testing in C++
• PyUnit.

See Also

• Programming with Assertions
• Design by Contract with Extensible C#
• Test::Unit::Assertions
• Why and How: Ruby (and Rails) Unit Testing
• WHY EIFFEL IS BETTER THAN C++
• xUnit Patterns

==