CSC/ECE 517 Fall 2007/wiki3 1 sa: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
 
(39 intermediate revisions by 2 users not shown)
Line 1: Line 1:
'''Support for assertions in various o-o programming languages'''
'''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? ''
''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=
=Introduction=
Line 60: Line 60:
Java supports runtime assertions since it is a statically typed language. It also allows specifying the pre-condition and post-condition, internal invariant type of assertions.
Java supports runtime assertions since it is a statically typed language. It also allows specifying the pre-condition and post-condition, internal invariant type of assertions.


A very simple switch-case example can be formulated as follows where an assertion is used for the default case.
A very simple switch-case example can be formulated as follows where an assertion is used for the default case where the assert false statement is executed when none of the case statements are true.


  switch(color) {
  switch(color) {
Line 101: Line 101:


==== Assertions during Developmental Cycles ====
==== Assertions during Developmental Cycles ====
The ''assert'' macro is defined only if ''NDEBUG'' is not defined. Therefore, a programmer can define 'NDEBUG' using a ''#define NDEBUG''  during the release cycle to remove all assertions in the code. There is no performance penalty in this case.
The ''assert'' macro is defined only if ''NDEBUG'' is not defined. Therefore, a programmer can define ''NDEBUG'' using a ''#define NDEBUG''  during the release cycle to remove all assertions in the code. There is no performance penalty in this case as the preprocessor will remove all the debugging code.


==== Assertions in Design by Contract ====
==== Assertions in Design by Contract ====
Assertions in Design by Contract are supported in C++ using third party tools such as the DBC for C preprocessor, GNU Nana, C², or the Digital Mars C++ compiler.
Assertions in Design by Contract are supported in C++ using third party tools such as the DBC for C preprocessor, GNU Nana, C², or the Digital Mars C++ compiler.
==== Assertions in xUnit ====
In C++, there is no one standardized framework but it does have several testing frameworks with different APIs. A list of these can be found [http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks#C.2B.2B here].  Most of them are ports of JUnit to C++. Since, assertions are not native to C++, each testing unit defines its own assert macros and functions. In the example listed above the ''assert.h'' standard library provides the ''assert()'' function. If the testing framework is ''CPPUnit'', then the corresponding assert function is ''CPPUNIT_ASSERT(expression)''.


==Ruby==
==Ruby==
===Support for Assertions===
===Support for Assertions===
Ruby does not have native support for assertions. Assertions are supported using the ''Test::Unit'' framework. ''Test::Unit::Assertions '' contain the standard Test::Unit assertions. Please refer to the [http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit.html Official Ruby Documentation] for more information on using the ''Test::Unit'' framework.
Ruby does not have native support for assertions. Assertions are supported using the ''Test::Unit'' framework. ''Test::Unit::Assertions '' contain the standard Test::Unit assertions. Please refer to the [http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit.html Official Ruby Documentation] for more information on using the ''Test::Unit'' framework. An assertion failure will result in the exception ''AssertionFailedError'' being thrown with the pertinent information on where the assertion failed which, if required, can be ''rescued'' by the programmer.


===Types of assertions===
===Types of assertions===
Line 130: Line 133:


==== Assertions during Developmental Cycle ====
==== Assertions during Developmental Cycle ====
Since, Ruby does not have native support for assertions there is no way to turn off assertions during runtime unless the programmer explicitly does so.
Since, Ruby does not have native support for assertions there is no way to turn off assertions during runtime unless the programmer explicitly does so.However, since assertions in Ruby are part of the unit testing framework, they are expected to be used only in the test fixture and not in the actual development code.


==== Assertions in Design by Contract ====
==== Assertions in Design by Contract ====
Ruby support assertions in Design by Contract using third party libraries like Brian McCallister's DesignByContract, Ruby DBC or ruby-contract.
Ruby supports assertions in Design by Contract using third party libraries like Brian McCallister's DesignByContract, Ruby DBC or ruby-contract.
 
==== Assertions in xUnit ====
Ruby uses the ''Test::Unit'' framework for unit testing and the ''Test::Unit::Assertions'' provides the necessary assertion support. Some of the commonly used assert statements in Ruby are ''assert(), assert_equal(), assert_not_equal(), assert_nil(), assert_not_nil(), assert_same(), assert_not_same()''.


==Python==
==Python==
=== Support for Assertions ===
=== Support for Assertions ===
Assertions in Python are built into the language and are implemented using the ''assert'' statement.  The syntax for the ''assert'' statement is as follows:
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]
  assert_stmt::="assert" expression ["," expression]


The second expression is optional. Please refer to [http://docs.python.org/ref/assert.html Python Documentation] for more information on the ''assert'' statement syntax.
The second expression is optional. Please refer to [http://docs.python.org/ref/assert.html Python Documentation] for more information on the ''assert'' statement syntax. The exception ''AssertionError'' is thrown whenever an assertion fails and will usually result in the termination of the program.


=== Types of Assertions ===
=== Types of Assertions ===
Line 150: Line 156:
  assert x>0 #will be true as long as x>0
  assert x>0 #will be true as long as x>0


An ''AssertionError'' is raised whenever an assertions fails and usually terminates the program.  
In the example above, the expression ''x>0'' 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.
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.
Line 160: Line 166:
   assert type(name) is StringType, "name is not String: %s" % `name`
   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.
The string expression at the end of the ''assert statement'' is printed out only if the assertion fails.


==== Assertions during Developmental Cycle ====
==== Assertions during Developmental Cycle ====
Assertions in python are executed only in debug mode and can be disabled by passing the "-O" option to the python interpreter. This allows the developer to turn off assertions in the release builds to avoid unnecessary performance slowdowns.
Assertions in Python are executed only in debug mode and can be disabled by passing the "-O" option to the python interpreter. This allows the developer to turn off assertions in the release builds to avoid unnecessary performance slowdowns.


==== Assertions in Design by Contract ====
==== Assertions in Design by Contract ====
Python does not have native support for assertions in Design by Contract(DBC). However, there are third party libraries like PyDBC or Contracts for Python which add support for DBC.
Python does not have native support for assertions in Design by Contract(DBC). However, there are third party libraries like PyDBC or Contracts for Python which add support for DBC.
==== Assertions in xUnit ====
The standard Unit testing framework in Python is [http://pyunit.sourceforge.net/ 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.


==Eiffel==
==Eiffel==
===Support for assertions===
===Support for assertions===
Eiffel has native support for assertions through Design by Contract.  
Eiffel has native support for assertions through Design by Contract. Here, the state of the code to be executed before and after execution is explicitly defined using pre-conditions and post-conditions. These conditions are also extracted and included in the documentation of the class which ensures that the documentation stays in sync with the code.
 
===Types of assertions===
===Types of assertions===


Line 192: Line 202:
</pre>
</pre>


=xUnit testing frameworks and assertions=
==== Assertions in xUnit ====
There are no unit testing frameworks for Eiffel. Design by Contract is the recommended way to test Eiffel code.
 
=Summary=
[[Image:Comparison.PNG]]
 


Different programming languages support Unit testing using frameworks specific to that language. In this section we briefly discuss for some o-o programming languages.
* '''Java'''
Java uses the JUnit testing framework. Here the assert functions are responsible for all the testing. Different assertion functions can be included in the code to run the required tests. Detailed dcoumentation is available in the official website for [http://www.junit.org/ JUnit].
* '''C++'''
In C++, there is no one standardized framework but it does have several testing frameworks with different APIs. A list of these can be found [http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks#C.2B.2B here].
* '''Ruby'''
In Ruby there is no native support for assertions. This feature is implemented using in the [http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html Test::Unit] framework
* '''Python'''
The standard Unit testing framework in Python is [http://pyunit.sourceforge.net/ PyUnit]. It is a part of the Python standard library. PyUnit is based on the JUnit framework.


=References=
=References=
Line 226: Line 232:
*[http://java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html Programming with Assertions]
*[http://java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html Programming with Assertions]
*[http://www.codeproject.com/cs/design/DbCwithXCSharp.asp Design by Contract with Extensible C#]
*[http://www.codeproject.com/cs/design/DbCwithXCSharp.asp Design by Contract with Extensible C#]
*[http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html Test::Unit::Assertions]
*[http://glu.ttono.us/articles/2005/10/30/why-and-how-ruby-and-rails-unit-testing Why and How: Ruby (and Rails) Unit Testing]
*[http://www.ntecs.de/old-hp/s-direktnet/Data/eiffel/EiffelCpp.txt WHY EIFFEL IS BETTER THAN C++]
*[http://xunitpatterns.com/Assertion%20Method.html xUnit Patterns]
==

Latest revision as of 20:39, 28 November 2007

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

"In computer programming, an assertion is a predicate (i.e., a true–false statement) placed in a program to indicate that the developer thinks that the predicate is always true at that place. Assertions are used to help specify programs and to reason about program correctness. For example, a precondition — an assertion placed at the beginning of a section of code — determines the set of states under which the code is expected to be executed. A postcondition — placed at the end — describes the expected state at the end of execution. "[1]

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

Following is a very simple example of an assertion in Java.

if (i % 4 == 0) {
       ...
   } else if (i % 4 == 1) {
       ...
   } else if (i % 4 == 2) {
       ...
   } else {
       assert i % 4 == 3 : i;
       ...
   }

In the above example we know that if the first three conditions are false then i % 4 has to evaluate to 3 and this is asserted using assert. Note that even in this case the assertion may fail if i is negative.

Usage

  • Design by Contract: Assertions may be specified at the class level (invariants) or on the method level (preconditions and postconditions). An invariant is a correctness condition imposed on a class, i.e., 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. This is a very common usage of assertions.
  • Development Cycle: During the development cycle, assertions are used as a powerful debugging tool. The point at which the assertion failure occurs the programmer is immediately notified so that he can go ahead and fix the bug.
  • 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

Java

Support for assertions

Java, when developed initially, did not have any built-in support for assertions. This was probably because it's exception handling feature was very powerful. However the (beta) release 1.4 of Java 2 included a built-in assertion facility. An assertion is a statement in the JavaTM programming language that enables you to test your assumptions about your program. Java Assertion Facility is a built in kind of support since Java 1.4 release. Java supports a very simple assertion mechanism that allows to formulate correctness conditions within methods. Assertion checking can be easily enabled and disabled and traces of assertions may be eliminated completely from class files. [3]

Types of assertions

Java supports runtime assertions since it is a statically typed language. It also allows specifying the pre-condition and post-condition, internal invariant type of assertions.

A very simple switch-case example can be formulated as follows where an assertion is used for the default case where the assert false statement is executed when none of the case statements are true.

switch(color) {
     case Color.RED:
       ...
       break;
     case Color.YELLOW:
       ...
       break;
     case Color.BLUE:
       ...
       break;
     case Color.GREEN:
       ...
     default:
       assert false : suit; 
   }

C++

Support for assertions

There is no native support for assertions in C++. Assertions are, however, part of the standard library header assert.h which defines the macro assert. The assert macro evaluates an expression and prints out a error message to standard error if the expression evaluates to zero. The actual message is dependent on the implementation and varies from compiler to compiler. In most cases, an assertion failure results in the termination of the program using abort.

Types of assertions

Runtime Assertions

The assert macro can be used for runtime assertions. A simple example is shown below:

 #include<assert.h>

 int main()
 {
   int x=3;
   int y=4;

   assert((x-y)>0); //false. Will terminate the program.
 }

The above example checks if the difference between x and y is greater than zero. In the example above, an assertion error will be thrown resulting in the termination of the program.

Assertions during Developmental Cycles

The assert macro is defined only if NDEBUG is not defined. Therefore, a programmer can define NDEBUG using a #define NDEBUG during the release cycle to remove all assertions in the code. There is no performance penalty in this case as the preprocessor will remove all the debugging code.

Assertions in Design by Contract

Assertions in Design by Contract are supported in C++ using third party tools such as the DBC for C preprocessor, GNU Nana, C², or the Digital Mars C++ compiler.

Assertions in xUnit

In C++, there is no one standardized framework but it does have several testing frameworks with different APIs. A list of these can be found here. Most of them are ports of JUnit to C++. Since, assertions are not native to C++, each testing unit defines its own assert macros and functions. In the example listed above the assert.h standard library provides the assert() function. If the testing framework is CPPUnit, then the corresponding assert function is CPPUNIT_ASSERT(expression).

Ruby

Support for Assertions

Ruby does not have native support for assertions. Assertions are supported using the Test::Unit framework. Test::Unit::Assertions contain the standard Test::Unit assertions. Please refer to the Official Ruby Documentation for more information on using the Test::Unit framework. An assertion failure will result in the exception AssertionFailedError being thrown with the pertinent information on where the assertion failed which, if required, can be rescued by the programmer.

Types of assertions

Runtime Assertions

The Test::Unit::Assertions provides a rich set of assertion functions. A simple example is shown below:

require "test/unit"

x=8
assert x>0 # will return true
assert_equal(x,7,"Equality test failed!") # False. Test will fail.
 

Other functions include assert_match for regular expression matching.

require "test/unit"
   
assert (/[a-z]+/, "Match12") # will fail.

A complete list of possible runtime assertions can be found at RubyDoc.

Assertions during Developmental Cycle

Since, Ruby does not have native support for assertions there is no way to turn off assertions during runtime unless the programmer explicitly does so.However, since assertions in Ruby are part of the unit testing framework, they are expected to be used only in the test fixture and not in the actual development code.

Assertions in Design by Contract

Ruby supports assertions in Design by Contract using third party libraries like Brian McCallister's DesignByContract, Ruby DBC or ruby-contract.

Assertions in xUnit

Ruby uses the Test::Unit framework for unit testing and the Test::Unit::Assertions provides the necessary assertion support. Some of the commonly used assert statements in Ruby are assert(), assert_equal(), assert_not_equal(), assert_nil(), assert_not_nil(), assert_same(), assert_not_same().

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. Please refer to Python Documentation for more information on the assert statement syntax. The exception AssertionError is thrown whenever an assertion fails and will usually result in the termination of the program.

Types of Assertions

Runtime Assertions

The example below checks whether a value of a variable is always positive using assertions in Python.

x=5
assert x>0 #will be true as long as x>0

In the example above, the expression x>0 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 during Developmental Cycle

Assertions in Python are executed only in debug mode and can be disabled by passing the "-O" option to the python interpreter. This allows the developer to turn off assertions in the release builds to avoid unnecessary performance slowdowns.

Assertions in Design by Contract

Python does not have native support for assertions in Design by Contract(DBC). However, there are third party libraries like PyDBC or Contracts for Python which add support for DBC.

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.

Eiffel

Support for assertions

Eiffel has native support for assertions through Design by Contract. Here, the state of the code to be executed before and after execution is explicitly defined using pre-conditions and post-conditions. These conditions are also extracted and included in the documentation of the class which ensures that the documentation stays in sync with the code.

Types of assertions

Design by Contract

Eiffel supports assertions only through Design by Contract. Eiffel uses the require statement to indicate pre-conditions and ensure statement for post-conditions. The example[1] below illustrates this using a simple dictionary insertion function.

put (x: ELEMENT; key: STRING) is
                     -- Insert x so that it will be retrievable through key.
             require
                     count <= capacity
                     not key.empty
             do
                     ... Some insertion algorithm ...
             ensure
                     has (x)
                     item (key) = x
                     count = old count + 1
             end

Assertions in xUnit

There are no unit testing frameworks for Eiffel. Design by Contract is the recommended way to test Eiffel code.

Summary


References

External Links

See Also

==