CSC/ECE 517 Fall 2010/ch6 6b AK: Difference between revisions
Line 36: | Line 36: | ||
1. Assertions in design by contract: Assertions can be a part of the documentation. They describe the state of the code before executing a particular statement and the state achieved after executing that statement. They can also specify certain invariants of a class.<br> | 1. Assertions in design by contract: Assertions can be a part of the documentation. They describe the state of the code before executing a particular statement and the state achieved after executing that statement. They can also specify certain invariants of a class.<br> | ||
2. Assertions for Runtime Checking: Assertions can be used in the actual code implementation to find out if the state of the code is consistent and holds valid values for all the variables taking part in the computations at that point. The main advantage of this approach is that the bug is discovered as soon as it is induced in the system, instead of finding it out later with the help of side effects. | 2. Assertions for Runtime Checking: Assertions can be used in the actual code implementation to find out if the state of the code is consistent and holds valid values for all the variables taking part in the computations at that point. The main advantage of this approach is that the bug is discovered as soon as it is induced in the system, instead of finding it out later with the help of side effects.<br> | ||
3. Assertions during the development cycle: Normally assertions are enabled during the development cycle by the programmer to find the bugs as quickly as possible. This helps in faster development and less number of bugs later on. | 3. Assertions during the development cycle: Normally assertions are enabled during the development cycle by the programmer to find the bugs as quickly as possible. This helps in faster development and less number of bugs later on.<br> | ||
4. Static assertions: Static assertions are performed at compile time and report a more evident kind of bugs which are very easy to spot and fix. | 4. Static assertions: Static assertions are performed at compile time and report a more evident kind of bugs which are very easy to spot and fix.<br> | ||
==Python== | ==Python== | ||
=== Support for Assertions === | === Support for Assertions === |
Revision as of 04:10, 17 November 2010
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]
Types of assertions in various o-o programming languages
There are different kinds of assertions that can be implemented. A few of them have been listed below.
- Basic assertions: This defines conditions that must be met at a particular line of code.
- Preconditions": Preconditions must be satisfied in order to call a method
- "Postconditions: Postconditions must be satisfied at exit point of the method
- Invariants: This defines state-space consistency for a class. It is evaluated at the entry and exit point of a class.
1. Assertions in design by contract: Assertions can be a part of the documentation. They describe the state of the code before executing a particular statement and the state achieved after executing that statement. They can also specify certain invariants of a class.
2. Assertions for Runtime Checking: Assertions can be used in the actual code implementation to find out if the state of the code is consistent and holds valid values for all the variables taking part in the computations at that point. The main advantage of this approach is that the bug is discovered as soon as it is induced in the system, instead of finding it out later with the help of side effects.
3. Assertions during the development cycle: Normally assertions are enabled during the development cycle by the programmer to find the bugs as quickly as possible. This helps in faster development and less number of bugs later on.
4. Static assertions: Static assertions are performed at compile time and report a more evident kind of bugs which are very easy to spot and fix.
Python
Support for Assertions
Assertions in Python are built into the language and are implemented using the assert statement. The syntax for the assert statement according to the official Python documentation is as follows:
assert_stmt::="assert" expression ["," expression]
The second expression is optional
Types of Assertions
Runtime Assertions
The example below checks whether a value of a variable is always positive using assertions in Python.
x=5 y=10 assert x<y
In the example above, the expression x<y will evaluate to true and therefore, no AssertionError is raised. The assert statement can also be used for type checking since python is a dynamically typed language. This is useful in making sure the type of the arguments to an function are correct. from types import *
def foo(x,name)
assert type(x) is IntType, "id is not an integer: %s" % `id` assert type(name) is StringType, "name is not String: %s" % `name`
The string expression at the end of the assert statement is printed out only if the assertion fails.
Assertions in xUnit
The standard Unit testing framework in Python is PyUnit. It is a part of the Python standard library. PyUnit is based on the JUnit framework. The pyUnit framework uses the built-in Python assert statement for assertions.
Java
Support for assertions
Types of assertions
C++
Support for assertions
Types of assertions
Runtime Assertions
Assertions during Developmental Cycles
Assertions in Design by Contract
Assertions in xUnit
Ruby
Support for Assertions
Types of assertions
Runtime Assertions
Assertions during Developmental Cycle
Assertions in Design by Contract
Assertions in xUnit
Eiffel
Support for assertions
Types of assertions
Design by Contract
Assertions in xUnit
Summary
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
==