Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2007/wiki3 1 sa

2007-11-28T20:39:37Z

Kkrish: /* Assertions in XUnit */

'''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==

<blockquote> "''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]</blockquote>

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:

<pre>
#include<assert.h>

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

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

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 [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==
===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. 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 [http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html 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 [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 ===
==== 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 [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==
===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[http://archive.eiffel.com/doc/manuals/technology/contract/] below illustrates this using a simple dictionary insertion function.

<pre>
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

</pre>

==== 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]]

=References=

*[1] [http://en.wikipedia.org/wiki/Assertion_%28computing%29 Wikipedia Page] Assertions
*[2] Templ J.: Metaprogramming in Oberon, ETH Dissertation No. 10655, Zurich, 1994
*[3] [http://java.sun.com/j2se/1.4/docs/guide/lang/assert.html Sun Microsystems: Java Assertion Facility]

=External Links=
*[http://wiki.python.org/moin/UsingAssertionsEffectively Assertions in Python]
*[http://docs.python.org/ref/assert.html Assert statement in Python]
*[http://en.wikibooks.org/wiki/Ruby_Programming/Unit_testing Unit Testing in Ruby]
*[http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html Assertions in Ruby]
*[http://archive.eiffel.com/doc/manuals/technology/contract/ Design by Contract in Eiffel]
*[http://en.wikipedia.org/wiki/Design_by_contract Design by Contract]
*[http://wiki.rubyonrails.org/rails/pages/HowtoUnitTest More information on Ruby Unit Testing]
*[http://www.cplusplus.com/reference/clibrary/cassert/assert.html Assertions in C++]
*[http://www.junit.org/ JUnit]
*[http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks#C.2B.2B Unit testing in C++]
*[http://pyunit.sourceforge.net/ PyUnit].

=See Also=
*[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.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]

==

CSC/ECE 517 Fall 2007/wiki3 1 sa

2007-11-28T20:38:44Z

Kkrish:

'''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==

<blockquote> "''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]</blockquote>

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:

<pre>
#include<assert.h>

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

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

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 [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==
===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. 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 [http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html 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 [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 ===
==== 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 [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==
===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[http://archive.eiffel.com/doc/manuals/technology/contract/] below illustrates this using a simple dictionary insertion function.

<pre>
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

</pre>

==== 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]]

=References=

*[1] [http://en.wikipedia.org/wiki/Assertion_%28computing%29 Wikipedia Page] Assertions
*[2] Templ J.: Metaprogramming in Oberon, ETH Dissertation No. 10655, Zurich, 1994
*[3] [http://java.sun.com/j2se/1.4/docs/guide/lang/assert.html Sun Microsystems: Java Assertion Facility]

=External Links=
*[http://wiki.python.org/moin/UsingAssertionsEffectively Assertions in Python]
*[http://docs.python.org/ref/assert.html Assert statement in Python]
*[http://en.wikibooks.org/wiki/Ruby_Programming/Unit_testing Unit Testing in Ruby]
*[http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html Assertions in Ruby]
*[http://archive.eiffel.com/doc/manuals/technology/contract/ Design by Contract in Eiffel]
*[http://en.wikipedia.org/wiki/Design_by_contract Design by Contract]
*[http://wiki.rubyonrails.org/rails/pages/HowtoUnitTest More information on Ruby Unit Testing]
*[http://www.cplusplus.com/reference/clibrary/cassert/assert.html Assertions in C++]
*[http://www.junit.org/ JUnit]
*[http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks#C.2B.2B Unit testing in C++]
*[http://pyunit.sourceforge.net/ PyUnit].

=See Also=
*[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.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]

==

CSC/ECE 517 Fall 2007/wiki3 1 sa

2007-11-28T20:35:16Z

Kkrish: /* 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? ''

=Introduction=

==Definition==

<blockquote> "''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]</blockquote>

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:

<pre>
#include<assert.h>

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

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

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 [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==
===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. 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 [http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html 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(boolean, [message]), assert_equal(expected, actual, [message]), assert_not_equal(expected, actual, [message]), assert_nil(object, [message]), assert_not_nil(object, [message]), assert_same(expected, actual, [message]), assert_not_same(expected, actual, [message])''.

==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 [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 ===
==== 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 [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==
===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[http://archive.eiffel.com/doc/manuals/technology/contract/] below illustrates this using a simple dictionary insertion function.

<pre>
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

</pre>

==== 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]]

=References=

*[1] [http://en.wikipedia.org/wiki/Assertion_%28computing%29 Wikipedia Page] Assertions
*[2] Templ J.: Metaprogramming in Oberon, ETH Dissertation No. 10655, Zurich, 1994
*[3] [http://java.sun.com/j2se/1.4/docs/guide/lang/assert.html Sun Microsystems: Java Assertion Facility]

=External Links=
*[http://wiki.python.org/moin/UsingAssertionsEffectively Assertions in Python]
*[http://docs.python.org/ref/assert.html Assert statement in Python]
*[http://en.wikibooks.org/wiki/Ruby_Programming/Unit_testing Unit Testing in Ruby]
*[http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html Assertions in Ruby]
*[http://archive.eiffel.com/doc/manuals/technology/contract/ Design by Contract in Eiffel]
*[http://en.wikipedia.org/wiki/Design_by_contract Design by Contract]
*[http://wiki.rubyonrails.org/rails/pages/HowtoUnitTest More information on Ruby Unit Testing]
*[http://www.cplusplus.com/reference/clibrary/cassert/assert.html Assertions in C++]
*[http://www.junit.org/ JUnit]
*[http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks#C.2B.2B Unit testing in C++]
*[http://pyunit.sourceforge.net/ PyUnit].

=See Also=
*[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.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]

CSC/ECE 517 Fall 2007/wiki3 1 sa

2007-11-28T20:34:31Z

Kkrish:

=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==

<blockquote> "''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]</blockquote>

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:

<pre>
#include<assert.h>

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

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

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 [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==
===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. 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 [http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html 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(boolean, [message]), assert_equal(expected, actual, [message]), assert_not_equal(expected, actual, [message]), assert_nil(object, [message]), assert_not_nil(object, [message]), assert_same(expected, actual, [message]), assert_not_same(expected, actual, [message])''.

==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 [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 ===
==== 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 [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==
===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[http://archive.eiffel.com/doc/manuals/technology/contract/] below illustrates this using a simple dictionary insertion function.

<pre>
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

</pre>

==== 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]]

=References=

*[1] [http://en.wikipedia.org/wiki/Assertion_%28computing%29 Wikipedia Page] Assertions
*[2] Templ J.: Metaprogramming in Oberon, ETH Dissertation No. 10655, Zurich, 1994
*[3] [http://java.sun.com/j2se/1.4/docs/guide/lang/assert.html Sun Microsystems: Java Assertion Facility]

=External Links=
*[http://wiki.python.org/moin/UsingAssertionsEffectively Assertions in Python]
*[http://docs.python.org/ref/assert.html Assert statement in Python]
*[http://en.wikibooks.org/wiki/Ruby_Programming/Unit_testing Unit Testing in Ruby]
*[http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html Assertions in Ruby]
*[http://archive.eiffel.com/doc/manuals/technology/contract/ Design by Contract in Eiffel]
*[http://en.wikipedia.org/wiki/Design_by_contract Design by Contract]
*[http://wiki.rubyonrails.org/rails/pages/HowtoUnitTest More information on Ruby Unit Testing]
*[http://www.cplusplus.com/reference/clibrary/cassert/assert.html Assertions in C++]
*[http://www.junit.org/ JUnit]
*[http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks#C.2B.2B Unit testing in C++]
*[http://pyunit.sourceforge.net/ PyUnit].

=See Also=
*[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.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]

CSC/ECE 517 Fall 2007/wiki3 1 sa

2007-11-28T20:33:28Z

Kkrish: /* Eiffel */

'''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==

<blockquote> "''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]</blockquote>

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:

<pre>
#include<assert.h>

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

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

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 [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==
===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. 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 [http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html 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(boolean, [message]), assert_equal(expected, actual, [message]), assert_not_equal(expected, actual, [message]), assert_nil(object, [message]), assert_not_nil(object, [message]), assert_same(expected, actual, [message]), assert_not_same(expected, actual, [message])''.

==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 [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 ===
==== 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 [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==
===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[http://archive.eiffel.com/doc/manuals/technology/contract/] below illustrates this using a simple dictionary insertion function.

<pre>
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

</pre>

==== 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]]

=References=

*[1] [http://en.wikipedia.org/wiki/Assertion_%28computing%29 Wikipedia Page] Assertions
*[2] Templ J.: Metaprogramming in Oberon, ETH Dissertation No. 10655, Zurich, 1994
*[3] [http://java.sun.com/j2se/1.4/docs/guide/lang/assert.html Sun Microsystems: Java Assertion Facility]

=External Links=
*[http://wiki.python.org/moin/UsingAssertionsEffectively Assertions in Python]
*[http://docs.python.org/ref/assert.html Assert statement in Python]
*[http://en.wikibooks.org/wiki/Ruby_Programming/Unit_testing Unit Testing in Ruby]
*[http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html Assertions in Ruby]
*[http://archive.eiffel.com/doc/manuals/technology/contract/ Design by Contract in Eiffel]
*[http://en.wikipedia.org/wiki/Design_by_contract Design by Contract]
*[http://wiki.rubyonrails.org/rails/pages/HowtoUnitTest More information on Ruby Unit Testing]
*[http://www.cplusplus.com/reference/clibrary/cassert/assert.html Assertions in C++]
*[http://www.junit.org/ JUnit]
*[http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks#C.2B.2B Unit testing in C++]
*[http://pyunit.sourceforge.net/ PyUnit].

=See Also=
*[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.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]

CSC/ECE 517 Fall 2007/wiki3 1 sa

2007-11-28T20:20:00Z

Kkrish: /* == */

'''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==

<blockquote> "''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]</blockquote>

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:

<pre>
#include<assert.h>

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

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

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 [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.

==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 [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===
====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 [http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html 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.

==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 [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 ===
==== 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 [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==
===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[http://archive.eiffel.com/doc/manuals/technology/contract/] below illustrates this using a simple dictionary insertion function.

<pre>
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

</pre>

=Summary=
[[Image:Comparison.PNG]]

=xUnit testing frameworks and assertions=

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=

*[1] [http://en.wikipedia.org/wiki/Assertion_%28computing%29 Wikipedia Page] Assertions
*[2] Templ J.: Metaprogramming in Oberon, ETH Dissertation No. 10655, Zurich, 1994
*[3] [http://java.sun.com/j2se/1.4/docs/guide/lang/assert.html Sun Microsystems: Java Assertion Facility]

=External Links=
*[http://wiki.python.org/moin/UsingAssertionsEffectively Assertions in Python]
*[http://docs.python.org/ref/assert.html Assert statement in Python]
*[http://en.wikibooks.org/wiki/Ruby_Programming/Unit_testing Unit Testing in Ruby]
*[http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html Assertions in Ruby]
*[http://archive.eiffel.com/doc/manuals/technology/contract/ Design by Contract in Eiffel]
*[http://en.wikipedia.org/wiki/Design_by_contract Design by Contract]
*[http://wiki.rubyonrails.org/rails/pages/HowtoUnitTest More information on Ruby Unit Testing]
*[http://www.cplusplus.com/reference/clibrary/cassert/assert.html Assertions in C++]
*[http://www.junit.org/ JUnit]
*[http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks#C.2B.2B Unit testing in C++]
*[http://pyunit.sourceforge.net/ PyUnit].

=See Also=
*[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.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]

CSC/ECE 517 Fall 2007/wiki3 1 sa

2007-11-28T20:18:45Z

Kkrish: /* Python */

'''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==

<blockquote> "''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]</blockquote>

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:

<pre>
#include<assert.h>

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

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

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 [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.

==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 [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===
====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 [http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html 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.

==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 [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 ===
==== 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 [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==
===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[http://archive.eiffel.com/doc/manuals/technology/contract/] below illustrates this using a simple dictionary insertion function.

<pre>
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

</pre>

=Summary=
[[Image:Comparison.PNG]]

=xUnit testing frameworks and assertions=

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=

*[1] [http://en.wikipedia.org/wiki/Assertion_%28computing%29 Wikipedia Page] Assertions
*[2] Templ J.: Metaprogramming in Oberon, ETH Dissertation No. 10655, Zurich, 1994
*[3] [http://java.sun.com/j2se/1.4/docs/guide/lang/assert.html Sun Microsystems: Java Assertion Facility]

=External Links=
*[http://wiki.python.org/moin/UsingAssertionsEffectively Assertions in Python]
*[http://docs.python.org/ref/assert.html Assert statement in Python]
*[http://en.wikibooks.org/wiki/Ruby_Programming/Unit_testing Unit Testing in Ruby]
*[http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html Assertions in Ruby]
*[http://archive.eiffel.com/doc/manuals/technology/contract/ Design by Contract in Eiffel]
*[http://en.wikipedia.org/wiki/Design_by_contract Design by Contract]
*[http://wiki.rubyonrails.org/rails/pages/HowtoUnitTest More information on Ruby Unit Testing]
*[http://www.cplusplus.com/reference/clibrary/cassert/assert.html Assertions in C++]
*[http://www.junit.org/ JUnit]
*[http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks#C.2B.2B Unit testing in C++]
*[http://pyunit.sourceforge.net/ PyUnit].

=See Also=
*[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.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]

CSC/ECE 517 Fall 2007/wiki3 1 sa

2007-11-28T20:16:48Z

Kkrish: /* Assertions in XUnit */

'''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==

<blockquote> "''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]</blockquote>

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:

<pre>
#include<assert.h>

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

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

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 [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.

==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 [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===
====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 [http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html 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.

==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 [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 ===
==== 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.

==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[http://archive.eiffel.com/doc/manuals/technology/contract/] below illustrates this using a simple dictionary insertion function.

<pre>
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

</pre>

=Summary=
[[Image:Comparison.PNG]]

=xUnit testing frameworks and assertions=

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=

*[1] [http://en.wikipedia.org/wiki/Assertion_%28computing%29 Wikipedia Page] Assertions
*[2] Templ J.: Metaprogramming in Oberon, ETH Dissertation No. 10655, Zurich, 1994
*[3] [http://java.sun.com/j2se/1.4/docs/guide/lang/assert.html Sun Microsystems: Java Assertion Facility]

=External Links=
*[http://wiki.python.org/moin/UsingAssertionsEffectively Assertions in Python]
*[http://docs.python.org/ref/assert.html Assert statement in Python]
*[http://en.wikibooks.org/wiki/Ruby_Programming/Unit_testing Unit Testing in Ruby]
*[http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html Assertions in Ruby]
*[http://archive.eiffel.com/doc/manuals/technology/contract/ Design by Contract in Eiffel]
*[http://en.wikipedia.org/wiki/Design_by_contract Design by Contract]
*[http://wiki.rubyonrails.org/rails/pages/HowtoUnitTest More information on Ruby Unit Testing]
*[http://www.cplusplus.com/reference/clibrary/cassert/assert.html Assertions in C++]
*[http://www.junit.org/ JUnit]
*[http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks#C.2B.2B Unit testing in C++]
*[http://pyunit.sourceforge.net/ PyUnit].

=See Also=
*[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.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]

CSC/ECE 517 Fall 2007/wiki3 1 sa

2007-11-28T20:15:52Z

Kkrish: /* Ruby */

'''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==

<blockquote> "''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]</blockquote>

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:

<pre>
#include<assert.h>

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

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

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 [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.

==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 [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===
====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 [http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html 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 assertion support as described above.

==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 [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 ===
==== 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.

==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[http://archive.eiffel.com/doc/manuals/technology/contract/] below illustrates this using a simple dictionary insertion function.

<pre>
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

</pre>

=Summary=
[[Image:Comparison.PNG]]

=xUnit testing frameworks and assertions=

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=

*[1] [http://en.wikipedia.org/wiki/Assertion_%28computing%29 Wikipedia Page] Assertions
*[2] Templ J.: Metaprogramming in Oberon, ETH Dissertation No. 10655, Zurich, 1994
*[3] [http://java.sun.com/j2se/1.4/docs/guide/lang/assert.html Sun Microsystems: Java Assertion Facility]

=External Links=
*[http://wiki.python.org/moin/UsingAssertionsEffectively Assertions in Python]
*[http://docs.python.org/ref/assert.html Assert statement in Python]
*[http://en.wikibooks.org/wiki/Ruby_Programming/Unit_testing Unit Testing in Ruby]
*[http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html Assertions in Ruby]
*[http://archive.eiffel.com/doc/manuals/technology/contract/ Design by Contract in Eiffel]
*[http://en.wikipedia.org/wiki/Design_by_contract Design by Contract]
*[http://wiki.rubyonrails.org/rails/pages/HowtoUnitTest More information on Ruby Unit Testing]
*[http://www.cplusplus.com/reference/clibrary/cassert/assert.html Assertions in C++]
*[http://www.junit.org/ JUnit]
*[http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks#C.2B.2B Unit testing in C++]
*[http://pyunit.sourceforge.net/ PyUnit].

=See Also=
*[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.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]

CSC/ECE 517 Fall 2007/wiki3 1 sa

2007-11-28T20:12:52Z

Kkrish: /* C++ */

'''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==

<blockquote> "''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]</blockquote>

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:

<pre>
#include<assert.h>

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

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

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 [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.

==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 [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===
====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 [http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html 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.

==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 [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 ===
==== 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.

==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[http://archive.eiffel.com/doc/manuals/technology/contract/] below illustrates this using a simple dictionary insertion function.

<pre>
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

</pre>

=Summary=
[[Image:Comparison.PNG]]

=xUnit testing frameworks and assertions=

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=

*[1] [http://en.wikipedia.org/wiki/Assertion_%28computing%29 Wikipedia Page] Assertions
*[2] Templ J.: Metaprogramming in Oberon, ETH Dissertation No. 10655, Zurich, 1994
*[3] [http://java.sun.com/j2se/1.4/docs/guide/lang/assert.html Sun Microsystems: Java Assertion Facility]

=External Links=
*[http://wiki.python.org/moin/UsingAssertionsEffectively Assertions in Python]
*[http://docs.python.org/ref/assert.html Assert statement in Python]
*[http://en.wikibooks.org/wiki/Ruby_Programming/Unit_testing Unit Testing in Ruby]
*[http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html Assertions in Ruby]
*[http://archive.eiffel.com/doc/manuals/technology/contract/ Design by Contract in Eiffel]
*[http://en.wikipedia.org/wiki/Design_by_contract Design by Contract]
*[http://wiki.rubyonrails.org/rails/pages/HowtoUnitTest More information on Ruby Unit Testing]
*[http://www.cplusplus.com/reference/clibrary/cassert/assert.html Assertions in C++]
*[http://www.junit.org/ JUnit]
*[http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks#C.2B.2B Unit testing in C++]
*[http://pyunit.sourceforge.net/ PyUnit].

=See Also=
*[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.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]

CSC/ECE 517 Fall 2007/wiki3 1 sa

2007-11-28T18:53:54Z

Kkrish: /* Support for assertions */

'''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==

<blockquote> "''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]</blockquote>

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:

<pre>
#include<assert.h>

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

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

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.

==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 [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===
====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 [http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html 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 support assertions in Design by Contract using third party libraries like Brian McCallister's DesignByContract, Ruby DBC or ruby-contract.

==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 [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 ===
==== 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.

==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[http://archive.eiffel.com/doc/manuals/technology/contract/] below illustrates this using a simple dictionary insertion function.

<pre>
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

</pre>

=xUnit testing frameworks and assertions=

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=

*[1] [http://en.wikipedia.org/wiki/Assertion_%28computing%29 Wikipedia Page] Assertions
*[2] Templ J.: Metaprogramming in Oberon, ETH Dissertation No. 10655, Zurich, 1994
*[3] [http://java.sun.com/j2se/1.4/docs/guide/lang/assert.html Sun Microsystems: Java Assertion Facility]

=External Links=
*[http://wiki.python.org/moin/UsingAssertionsEffectively Assertions in Python]
*[http://docs.python.org/ref/assert.html Assert statement in Python]
*[http://en.wikibooks.org/wiki/Ruby_Programming/Unit_testing Unit Testing in Ruby]
*[http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html Assertions in Ruby]
*[http://archive.eiffel.com/doc/manuals/technology/contract/ Design by Contract in Eiffel]
*[http://en.wikipedia.org/wiki/Design_by_contract Design by Contract]
*[http://wiki.rubyonrails.org/rails/pages/HowtoUnitTest More information on Ruby Unit Testing]
*[http://www.cplusplus.com/reference/clibrary/cassert/assert.html Assertions in C++]
*[http://www.junit.org/ JUnit]
*[http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks#C.2B.2B Unit testing in C++]
*[http://pyunit.sourceforge.net/ PyUnit].

=See Also=
*[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.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++]

CSC/ECE 517 Fall 2007/wiki3 1 sa

2007-11-28T18:53:19Z

Kkrish: /* Support for assertions */

'''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==

<blockquote> "''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]</blockquote>

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:

<pre>
#include<assert.h>

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

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

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.

==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 [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===
====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 [http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html 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 support assertions in Design by Contract using third party libraries like Brian McCallister's DesignByContract, Ruby DBC or ruby-contract.

==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 [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 ===
==== 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.

==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 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[http://archive.eiffel.com/doc/manuals/technology/contract/] below illustrates this using a simple dictionary insertion function.

<pre>
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

</pre>

=xUnit testing frameworks and assertions=

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=

*[1] [http://en.wikipedia.org/wiki/Assertion_%28computing%29 Wikipedia Page] Assertions
*[2] Templ J.: Metaprogramming in Oberon, ETH Dissertation No. 10655, Zurich, 1994
*[3] [http://java.sun.com/j2se/1.4/docs/guide/lang/assert.html Sun Microsystems: Java Assertion Facility]

=External Links=
*[http://wiki.python.org/moin/UsingAssertionsEffectively Assertions in Python]
*[http://docs.python.org/ref/assert.html Assert statement in Python]
*[http://en.wikibooks.org/wiki/Ruby_Programming/Unit_testing Unit Testing in Ruby]
*[http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html Assertions in Ruby]
*[http://archive.eiffel.com/doc/manuals/technology/contract/ Design by Contract in Eiffel]
*[http://en.wikipedia.org/wiki/Design_by_contract Design by Contract]
*[http://wiki.rubyonrails.org/rails/pages/HowtoUnitTest More information on Ruby Unit Testing]
*[http://www.cplusplus.com/reference/clibrary/cassert/assert.html Assertions in C++]
*[http://www.junit.org/ JUnit]
*[http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks#C.2B.2B Unit testing in C++]
*[http://pyunit.sourceforge.net/ PyUnit].

=See Also=
*[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.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++]

CSC/ECE 517 Fall 2007/wiki3 1 sa

2007-11-28T18:43:24Z

Kkrish: /* Support for Assertions */

'''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==

<blockquote> "''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]</blockquote>

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:

<pre>
#include<assert.h>

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

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

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.

==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 [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===
====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 [http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html 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 support assertions in Design by Contract using third party libraries like Brian McCallister's DesignByContract, Ruby DBC or ruby-contract.

==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 [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 ===
==== 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.

==Eiffel==
===Support for assertions===
Eiffel has native support for assertions through Design by Contract.
===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[http://archive.eiffel.com/doc/manuals/technology/contract/] below illustrates this using a simple dictionary insertion function.

<pre>
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

</pre>

=xUnit testing frameworks and assertions=

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=

*[1] [http://en.wikipedia.org/wiki/Assertion_%28computing%29 Wikipedia Page] Assertions
*[2] Templ J.: Metaprogramming in Oberon, ETH Dissertation No. 10655, Zurich, 1994
*[3] [http://java.sun.com/j2se/1.4/docs/guide/lang/assert.html Sun Microsystems: Java Assertion Facility]

=External Links=
*[http://wiki.python.org/moin/UsingAssertionsEffectively Assertions in Python]
*[http://docs.python.org/ref/assert.html Assert statement in Python]
*[http://en.wikibooks.org/wiki/Ruby_Programming/Unit_testing Unit Testing in Ruby]
*[http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html Assertions in Ruby]
*[http://archive.eiffel.com/doc/manuals/technology/contract/ Design by Contract in Eiffel]
*[http://en.wikipedia.org/wiki/Design_by_contract Design by Contract]
*[http://wiki.rubyonrails.org/rails/pages/HowtoUnitTest More information on Ruby Unit Testing]
*[http://www.cplusplus.com/reference/clibrary/cassert/assert.html Assertions in C++]
*[http://www.junit.org/ JUnit]
*[http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks#C.2B.2B Unit testing in C++]
*[http://pyunit.sourceforge.net/ PyUnit].

=See Also=
*[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.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++]

CSC/ECE 517 Fall 2007/wiki3 1 sa

2007-11-28T18:42:23Z

Kkrish: /* Support for Assertions */

'''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==

<blockquote> "''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]</blockquote>

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:

<pre>
#include<assert.h>

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

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

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.

==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 [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===
====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 [http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html 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 support assertions in Design by Contract using third party libraries like Brian McCallister's DesignByContract, Ruby DBC or ruby-contract.

==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 [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 terminate 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.

==Eiffel==
===Support for assertions===
Eiffel has native support for assertions through Design by Contract.
===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[http://archive.eiffel.com/doc/manuals/technology/contract/] below illustrates this using a simple dictionary insertion function.

<pre>
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

</pre>

=xUnit testing frameworks and assertions=

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=

*[1] [http://en.wikipedia.org/wiki/Assertion_%28computing%29 Wikipedia Page] Assertions
*[2] Templ J.: Metaprogramming in Oberon, ETH Dissertation No. 10655, Zurich, 1994
*[3] [http://java.sun.com/j2se/1.4/docs/guide/lang/assert.html Sun Microsystems: Java Assertion Facility]

=External Links=
*[http://wiki.python.org/moin/UsingAssertionsEffectively Assertions in Python]
*[http://docs.python.org/ref/assert.html Assert statement in Python]
*[http://en.wikibooks.org/wiki/Ruby_Programming/Unit_testing Unit Testing in Ruby]
*[http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html Assertions in Ruby]
*[http://archive.eiffel.com/doc/manuals/technology/contract/ Design by Contract in Eiffel]
*[http://en.wikipedia.org/wiki/Design_by_contract Design by Contract]
*[http://wiki.rubyonrails.org/rails/pages/HowtoUnitTest More information on Ruby Unit Testing]
*[http://www.cplusplus.com/reference/clibrary/cassert/assert.html Assertions in C++]
*[http://www.junit.org/ JUnit]
*[http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks#C.2B.2B Unit testing in C++]
*[http://pyunit.sourceforge.net/ PyUnit].

=See Also=
*[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.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++]

CSC/ECE 517 Fall 2007/wiki3 1 sa

2007-11-28T18:41:52Z

Kkrish: /* Runtime Assertions */

'''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==

<blockquote> "''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]</blockquote>

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:

<pre>
#include<assert.h>

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

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

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.

==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 [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===
====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 [http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html 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 support assertions in Design by Contract using third party libraries like Brian McCallister's DesignByContract, Ruby DBC or ruby-contract.

==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 [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.

=== 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.

==Eiffel==
===Support for assertions===
Eiffel has native support for assertions through Design by Contract.
===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[http://archive.eiffel.com/doc/manuals/technology/contract/] below illustrates this using a simple dictionary insertion function.

<pre>
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

</pre>

=xUnit testing frameworks and assertions=

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=

*[1] [http://en.wikipedia.org/wiki/Assertion_%28computing%29 Wikipedia Page] Assertions
*[2] Templ J.: Metaprogramming in Oberon, ETH Dissertation No. 10655, Zurich, 1994
*[3] [http://java.sun.com/j2se/1.4/docs/guide/lang/assert.html Sun Microsystems: Java Assertion Facility]

=External Links=
*[http://wiki.python.org/moin/UsingAssertionsEffectively Assertions in Python]
*[http://docs.python.org/ref/assert.html Assert statement in Python]
*[http://en.wikibooks.org/wiki/Ruby_Programming/Unit_testing Unit Testing in Ruby]
*[http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html Assertions in Ruby]
*[http://archive.eiffel.com/doc/manuals/technology/contract/ Design by Contract in Eiffel]
*[http://en.wikipedia.org/wiki/Design_by_contract Design by Contract]
*[http://wiki.rubyonrails.org/rails/pages/HowtoUnitTest More information on Ruby Unit Testing]
*[http://www.cplusplus.com/reference/clibrary/cassert/assert.html Assertions in C++]
*[http://www.junit.org/ JUnit]
*[http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks#C.2B.2B Unit testing in C++]
*[http://pyunit.sourceforge.net/ PyUnit].

=See Also=
*[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.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++]

CSC/ECE 517 Fall 2007/wiki3 1 sa

2007-11-28T18:40:38Z

Kkrish: /* Assertions during Developmental Cycle */

'''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==

<blockquote> "''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]</blockquote>

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:

<pre>
#include<assert.h>

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

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

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.

==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 [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===
====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 [http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html 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 support assertions in Design by Contract using third party libraries like Brian McCallister's DesignByContract, Ruby DBC or ruby-contract.

==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 [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.

=== 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

An ''AssertionError'' is raised whenever an assertions fails and usually terminates the program.

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.

==Eiffel==
===Support for assertions===
Eiffel has native support for assertions through Design by Contract.
===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[http://archive.eiffel.com/doc/manuals/technology/contract/] below illustrates this using a simple dictionary insertion function.

<pre>
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

</pre>

=xUnit testing frameworks and assertions=

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=

*[1] [http://en.wikipedia.org/wiki/Assertion_%28computing%29 Wikipedia Page] Assertions
*[2] Templ J.: Metaprogramming in Oberon, ETH Dissertation No. 10655, Zurich, 1994
*[3] [http://java.sun.com/j2se/1.4/docs/guide/lang/assert.html Sun Microsystems: Java Assertion Facility]

=External Links=
*[http://wiki.python.org/moin/UsingAssertionsEffectively Assertions in Python]
*[http://docs.python.org/ref/assert.html Assert statement in Python]
*[http://en.wikibooks.org/wiki/Ruby_Programming/Unit_testing Unit Testing in Ruby]
*[http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html Assertions in Ruby]
*[http://archive.eiffel.com/doc/manuals/technology/contract/ Design by Contract in Eiffel]
*[http://en.wikipedia.org/wiki/Design_by_contract Design by Contract]
*[http://wiki.rubyonrails.org/rails/pages/HowtoUnitTest More information on Ruby Unit Testing]
*[http://www.cplusplus.com/reference/clibrary/cassert/assert.html Assertions in C++]
*[http://www.junit.org/ JUnit]
*[http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks#C.2B.2B Unit testing in C++]
*[http://pyunit.sourceforge.net/ PyUnit].

=See Also=
*[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.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++]

CSC/ECE 517 Fall 2007/wiki3 1 sa

2007-11-28T18:36:22Z

Kkrish: /* Support for Assertions */

'''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==

<blockquote> "''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]</blockquote>

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:

<pre>
#include<assert.h>

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

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

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.

==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 [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===
====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 [http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html 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 support assertions in Design by Contract using third party libraries like Brian McCallister's DesignByContract, Ruby DBC or ruby-contract.

==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 [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.

=== 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

An ''AssertionError'' is raised whenever an assertions fails and usually terminates the program.

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.

==Eiffel==
===Support for assertions===
Eiffel has native support for assertions through Design by Contract.
===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[http://archive.eiffel.com/doc/manuals/technology/contract/] below illustrates this using a simple dictionary insertion function.

<pre>
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

</pre>

=xUnit testing frameworks and assertions=

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=

*[1] [http://en.wikipedia.org/wiki/Assertion_%28computing%29 Wikipedia Page] Assertions
*[2] Templ J.: Metaprogramming in Oberon, ETH Dissertation No. 10655, Zurich, 1994
*[3] [http://java.sun.com/j2se/1.4/docs/guide/lang/assert.html Sun Microsystems: Java Assertion Facility]

=External Links=
*[http://wiki.python.org/moin/UsingAssertionsEffectively Assertions in Python]
*[http://docs.python.org/ref/assert.html Assert statement in Python]
*[http://en.wikibooks.org/wiki/Ruby_Programming/Unit_testing Unit Testing in Ruby]
*[http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html Assertions in Ruby]
*[http://archive.eiffel.com/doc/manuals/technology/contract/ Design by Contract in Eiffel]
*[http://en.wikipedia.org/wiki/Design_by_contract Design by Contract]
*[http://wiki.rubyonrails.org/rails/pages/HowtoUnitTest More information on Ruby Unit Testing]
*[http://www.cplusplus.com/reference/clibrary/cassert/assert.html Assertions in C++]
*[http://www.junit.org/ JUnit]
*[http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks#C.2B.2B Unit testing in C++]
*[http://pyunit.sourceforge.net/ PyUnit].

=See Also=
*[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.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++]

CSC/ECE 517 Fall 2007/wiki3 1 sa

2007-11-28T18:32:40Z

Kkrish: /* Assertions during Developmental Cycle */

'''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==

<blockquote> "''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]</blockquote>

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:

<pre>
#include<assert.h>

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

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

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.

==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 [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===
====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 [http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html 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 support assertions in Design by Contract using third party libraries like Brian McCallister's DesignByContract, Ruby DBC or ruby-contract.

==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 is as follows:

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.

=== 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

An ''AssertionError'' is raised whenever an assertions fails and usually terminates the program.

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.

==Eiffel==
===Support for assertions===
Eiffel has native support for assertions through Design by Contract.
===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[http://archive.eiffel.com/doc/manuals/technology/contract/] below illustrates this using a simple dictionary insertion function.

<pre>
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

</pre>

=xUnit testing frameworks and assertions=

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=

*[1] [http://en.wikipedia.org/wiki/Assertion_%28computing%29 Wikipedia Page] Assertions
*[2] Templ J.: Metaprogramming in Oberon, ETH Dissertation No. 10655, Zurich, 1994
*[3] [http://java.sun.com/j2se/1.4/docs/guide/lang/assert.html Sun Microsystems: Java Assertion Facility]

=External Links=
*[http://wiki.python.org/moin/UsingAssertionsEffectively Assertions in Python]
*[http://docs.python.org/ref/assert.html Assert statement in Python]
*[http://en.wikibooks.org/wiki/Ruby_Programming/Unit_testing Unit Testing in Ruby]
*[http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html Assertions in Ruby]
*[http://archive.eiffel.com/doc/manuals/technology/contract/ Design by Contract in Eiffel]
*[http://en.wikipedia.org/wiki/Design_by_contract Design by Contract]
*[http://wiki.rubyonrails.org/rails/pages/HowtoUnitTest More information on Ruby Unit Testing]
*[http://www.cplusplus.com/reference/clibrary/cassert/assert.html Assertions in C++]
*[http://www.junit.org/ JUnit]
*[http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks#C.2B.2B Unit testing in C++]
*[http://pyunit.sourceforge.net/ PyUnit].

=See Also=
*[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.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++]

CSC/ECE 517 Fall 2007/wiki3 1 sa

2007-11-28T18:27:11Z

Kkrish: /* Support for Assertions */

'''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==

<blockquote> "''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]</blockquote>

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:

<pre>
#include<assert.h>

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

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

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.

==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 [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===
====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 [http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html 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.

==== 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.

==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 is as follows:

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.

=== 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

An ''AssertionError'' is raised whenever an assertions fails and usually terminates the program.

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.

==Eiffel==
===Support for assertions===
Eiffel has native support for assertions through Design by Contract.
===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[http://archive.eiffel.com/doc/manuals/technology/contract/] below illustrates this using a simple dictionary insertion function.

<pre>
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

</pre>

=xUnit testing frameworks and assertions=

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=

*[1] [http://en.wikipedia.org/wiki/Assertion_%28computing%29 Wikipedia Page] Assertions
*[2] Templ J.: Metaprogramming in Oberon, ETH Dissertation No. 10655, Zurich, 1994
*[3] [http://java.sun.com/j2se/1.4/docs/guide/lang/assert.html Sun Microsystems: Java Assertion Facility]

=External Links=
*[http://wiki.python.org/moin/UsingAssertionsEffectively Assertions in Python]
*[http://docs.python.org/ref/assert.html Assert statement in Python]
*[http://en.wikibooks.org/wiki/Ruby_Programming/Unit_testing Unit Testing in Ruby]
*[http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html Assertions in Ruby]
*[http://archive.eiffel.com/doc/manuals/technology/contract/ Design by Contract in Eiffel]
*[http://en.wikipedia.org/wiki/Design_by_contract Design by Contract]
*[http://wiki.rubyonrails.org/rails/pages/HowtoUnitTest More information on Ruby Unit Testing]
*[http://www.cplusplus.com/reference/clibrary/cassert/assert.html Assertions in C++]
*[http://www.junit.org/ JUnit]
*[http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks#C.2B.2B Unit testing in C++]
*[http://pyunit.sourceforge.net/ PyUnit].

=See Also=
*[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#]

CSC/ECE 517 Fall 2007/wiki3 1 sa

2007-11-28T18:23:24Z

Kkrish: /* Support for Assertions */

'''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==

<blockquote> "''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]</blockquote>

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:

<pre>
#include<assert.h>

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

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

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.

==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 [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 which 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 [http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html 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.

==== 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.

==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 is as follows:

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.

=== 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

An ''AssertionError'' is raised whenever an assertions fails and usually terminates the program.

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.

==Eiffel==
===Support for assertions===
Eiffel has native support for assertions through Design by Contract.
===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[http://archive.eiffel.com/doc/manuals/technology/contract/] below illustrates this using a simple dictionary insertion function.

<pre>
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

</pre>

=xUnit testing frameworks and assertions=

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=

*[1] [http://en.wikipedia.org/wiki/Assertion_%28computing%29 Wikipedia Page] Assertions
*[2] Templ J.: Metaprogramming in Oberon, ETH Dissertation No. 10655, Zurich, 1994
*[3] [http://java.sun.com/j2se/1.4/docs/guide/lang/assert.html Sun Microsystems: Java Assertion Facility]

=External Links=
*[http://wiki.python.org/moin/UsingAssertionsEffectively Assertions in Python]
*[http://docs.python.org/ref/assert.html Assert statement in Python]
*[http://en.wikibooks.org/wiki/Ruby_Programming/Unit_testing Unit Testing in Ruby]
*[http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html Assertions in Ruby]
*[http://archive.eiffel.com/doc/manuals/technology/contract/ Design by Contract in Eiffel]
*[http://en.wikipedia.org/wiki/Design_by_contract Design by Contract]
*[http://wiki.rubyonrails.org/rails/pages/HowtoUnitTest More information on Ruby Unit Testing]
*[http://www.cplusplus.com/reference/clibrary/cassert/assert.html Assertions in C++]
*[http://www.junit.org/ JUnit]
*[http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks#C.2B.2B Unit testing in C++]
*[http://pyunit.sourceforge.net/ PyUnit].

=See Also=
*[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#]

CSC/ECE 517 Fall 2007/wiki3 1 sa

2007-11-28T18:19:10Z

Kkrish: /* Assertions during Developmental Cycles */

'''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==

<blockquote> "''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]</blockquote>

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.

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:

<pre>
#include<assert.h>

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

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

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.

==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 [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.

===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 [http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html 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.

==== 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.

==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 is as follows:

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.

=== 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

An ''AssertionError'' is raised whenever an assertions fails and usually terminates the program.

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.

==Eiffel==
===Support for assertions===
Eiffel has native support for assertions through Design by Contract.
===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[http://archive.eiffel.com/doc/manuals/technology/contract/] below illustrates this using a simple dictionary insertion function.

<pre>
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

</pre>

=xUnit testing frameworks and assertions=

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=

*[1] [http://en.wikipedia.org/wiki/Assertion_%28computing%29 Wikipedia Page] Assertions
*[2] Templ J.: Metaprogramming in Oberon, ETH Dissertation No. 10655, Zurich, 1994
*[3] [http://java.sun.com/j2se/1.4/docs/guide/lang/assert.html Sun Microsystems: Java Assertion Facility]

=External Links=
*[http://wiki.python.org/moin/UsingAssertionsEffectively Assertions in Python]
*[http://docs.python.org/ref/assert.html Assert statement in Python]
*[http://en.wikibooks.org/wiki/Ruby_Programming/Unit_testing Unit Testing in Ruby]
*[http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html Assertions in Ruby]
*[http://archive.eiffel.com/doc/manuals/technology/contract/ Design by Contract in Eiffel]
*[http://en.wikipedia.org/wiki/Design_by_contract Design by Contract]
*[http://wiki.rubyonrails.org/rails/pages/HowtoUnitTest More information on Ruby Unit Testing]
*[http://www.cplusplus.com/reference/clibrary/cassert/assert.html Assertions in C++]
*[http://www.junit.org/ JUnit]
*[http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks#C.2B.2B Unit testing in C++]
*[http://pyunit.sourceforge.net/ PyUnit].

=See Also=
*[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#]

CSC/ECE 517 Fall 2007/wiki3 1 sa

2007-11-28T18:16:43Z

Kkrish: /* Runtime Assertions */

'''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==

<blockquote> "''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]</blockquote>

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.

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:

<pre>
#include<assert.h>

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

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

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.

==== 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.

==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 [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.

===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 [http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html 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.

==== 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.

==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 is as follows:

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.

=== 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

An ''AssertionError'' is raised whenever an assertions fails and usually terminates the program.

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.

==Eiffel==
===Support for assertions===
Eiffel has native support for assertions through Design by Contract.
===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[http://archive.eiffel.com/doc/manuals/technology/contract/] below illustrates this using a simple dictionary insertion function.

<pre>
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

</pre>

=xUnit testing frameworks and assertions=

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=

*[1] [http://en.wikipedia.org/wiki/Assertion_%28computing%29 Wikipedia Page] Assertions
*[2] Templ J.: Metaprogramming in Oberon, ETH Dissertation No. 10655, Zurich, 1994
*[3] [http://java.sun.com/j2se/1.4/docs/guide/lang/assert.html Sun Microsystems: Java Assertion Facility]

=External Links=
*[http://wiki.python.org/moin/UsingAssertionsEffectively Assertions in Python]
*[http://docs.python.org/ref/assert.html Assert statement in Python]
*[http://en.wikibooks.org/wiki/Ruby_Programming/Unit_testing Unit Testing in Ruby]
*[http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html Assertions in Ruby]
*[http://archive.eiffel.com/doc/manuals/technology/contract/ Design by Contract in Eiffel]
*[http://en.wikipedia.org/wiki/Design_by_contract Design by Contract]
*[http://wiki.rubyonrails.org/rails/pages/HowtoUnitTest More information on Ruby Unit Testing]
*[http://www.cplusplus.com/reference/clibrary/cassert/assert.html Assertions in C++]
*[http://www.junit.org/ JUnit]
*[http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks#C.2B.2B Unit testing in C++]
*[http://pyunit.sourceforge.net/ PyUnit].

=See Also=
*[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#]

CSC/ECE 517 Fall 2007/wiki3 1 sa

2007-11-28T18:12:20Z

Kkrish: /* Support for assertions */

'''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==

<blockquote> "''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]</blockquote>

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.

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:

<pre>
#include<assert.h>

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

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

An assertion failure will usually result 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.

==== 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.

==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 [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.

===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 [http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html 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.

==== 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.

==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 is as follows:

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.

=== 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

An ''AssertionError'' is raised whenever an assertions fails and usually terminates the program.

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.

==Eiffel==
===Support for assertions===
Eiffel has native support for assertions through Design by Contract.
===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[http://archive.eiffel.com/doc/manuals/technology/contract/] below illustrates this using a simple dictionary insertion function.

<pre>
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

</pre>

=xUnit testing frameworks and assertions=

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=

*[1] [http://en.wikipedia.org/wiki/Assertion_%28computing%29 Wikipedia Page] Assertions
*[2] Templ J.: Metaprogramming in Oberon, ETH Dissertation No. 10655, Zurich, 1994
*[3] [http://java.sun.com/j2se/1.4/docs/guide/lang/assert.html Sun Microsystems: Java Assertion Facility]

=External Links=
*[http://wiki.python.org/moin/UsingAssertionsEffectively Assertions in Python]
*[http://docs.python.org/ref/assert.html Assert statement in Python]
*[http://en.wikibooks.org/wiki/Ruby_Programming/Unit_testing Unit Testing in Ruby]
*[http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html Assertions in Ruby]
*[http://archive.eiffel.com/doc/manuals/technology/contract/ Design by Contract in Eiffel]
*[http://en.wikipedia.org/wiki/Design_by_contract Design by Contract]
*[http://wiki.rubyonrails.org/rails/pages/HowtoUnitTest More information on Ruby Unit Testing]
*[http://www.cplusplus.com/reference/clibrary/cassert/assert.html Assertions in C++]
*[http://www.junit.org/ JUnit]
*[http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks#C.2B.2B Unit testing in C++]
*[http://pyunit.sourceforge.net/ PyUnit].

=See Also=
*[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#]

CSC/ECE 517 Fall 2007/wiki3 1 sa

2007-11-28T17:41:13Z

Kkrish:

'''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==

<blockquote> "''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]</blockquote>

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 of the 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 teh 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.

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''.

===Types of assertions===
==== Runtime Assertions ====
The ''assert'' macro can be used for runtime assertions. A simple example is shown below:

<pre>
#include<assert.h>

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

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

An assertion failure will usually result 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.

==== 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.

==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 [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.

===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 [http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html 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.

==== 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.

==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 is as follows:

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.

=== 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

An ''AssertionError'' is raised whenever an assertions fails and usually terminates the program.

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.

==Eiffel==
===Support for assertions===
Eiffel has native support for assertions through Design by Contract.
===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[http://archive.eiffel.com/doc/manuals/technology/contract/] bellow illustrates this using a simple dictionary insertion function.

<pre>
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

</pre>

=xUnit testing frameworks and assertions=

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=

*[1] [http://en.wikipedia.org/wiki/Assertion_%28computing%29 Wikipedia Page] Assertions
*[2] Templ J.: Metaprogramming in Oberon, ETH Dissertation No. 10655, Zurich, 1994
*[3] [http://java.sun.com/j2se/1.4/docs/guide/lang/assert.html Sun Microsystems: Java Assertion Facility]

=External Links=
*[http://wiki.python.org/moin/UsingAssertionsEffectively Assertions in Python]
*[http://docs.python.org/ref/assert.html Assert statement in Python]
*[http://en.wikibooks.org/wiki/Ruby_Programming/Unit_testing Unit Testing in Ruby]
*[http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html Assertions in Ruby]
*[http://archive.eiffel.com/doc/manuals/technology/contract/ Design by Contract in Eiffel]
*[http://en.wikipedia.org/wiki/Design_by_contract Design by Contract]
*[http://wiki.rubyonrails.org/rails/pages/HowtoUnitTest More information on Ruby Unit Testing]
*[http://www.cplusplus.com/reference/clibrary/cassert/assert.html Assertions in C++]
*[http://www.junit.org/ JUnit]
*[http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks#C.2B.2B Unit testing in C++]
*[http://pyunit.sourceforge.net/ PyUnit].

CSC/ECE 517 Fall 2007/wiki3 1 sa

2007-11-19T19:58:56Z

Kkrish: /* External Links */

'''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==

<blockquote> "''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]</blockquote>

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 of the 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 teh 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 varios 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 swiych-case example can be formulated as follows where an assertion is used for the default case.

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''.

===Types of assertions===
==== Runtime Assertions ====
The ''assert'' macro can be used for runtime assertions. A simple example is shown below:

<pre>
#include<assert.h>

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

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

An assertion failue will usually result 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.

==== 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.

==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 [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.

===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 [http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html 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.

==== 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.

==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 is as follows:

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.

=== 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

An ''AssertionError'' is raised whenever an assertions fails and usually terminates the program.

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.

==Eiffel==
===Support for assertions===
Eiffel has native support for assertions through Design by Contract.
===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[http://archive.eiffel.com/doc/manuals/technology/contract/] bellow illustrates this using a simple dictionary insertion function.

<pre>
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

</pre>

=XUnit testing frameworks and assertions=

=References=

*[1] [http://en.wikipedia.org/wiki/Assertion_%28computing%29 Wikipedia Page] Assertions
*[2] Templ J.: Metaprogramming in Oberon, ETH Dissertation No. 10655, Zurich, 1994
*[3] [http://java.sun.com/j2se/1.4/docs/guide/lang/assert.html Sun Microsystems: Java Assertion Facility]

=External Links=
[http://wiki.python.org/moin/UsingAssertionsEffectively Assertions in Python]

[http://docs.python.org/ref/assert.html Assert statement in Python]

[http://en.wikibooks.org/wiki/Ruby_Programming/Unit_testing Unit Testing in Ruby]

[http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html Assertions in Ruby]

[http://archive.eiffel.com/doc/manuals/technology/contract/ Design by Contract in Eiffel]

[http://en.wikipedia.org/wiki/Design_by_contract Design by Contract]

[http://wiki.rubyonrails.org/rails/pages/HowtoUnitTest More information on Ruby Unit Testing]

[http://www.cplusplus.com/reference/clibrary/cassert/assert.html Assertions in C++]

CSC/ECE 517 Fall 2007/wiki3 1 sa

2007-11-19T19:19:08Z

Kkrish: /* Design by Contract */

CSC/ECE 517 Fall 2007/wiki3 1 sa

2007-11-19T19:17:08Z

Kkrish:

CSC/ECE 517 Fall 2007/wiki3 1 sa

2007-11-19T19:16:43Z

Kkrish: /* Eiffel */

CSC/ECE 517 Fall 2007/wiki3 1 sa

2007-11-19T18:55:38Z

Kkrish: /* Support for Assertions */

CSC/ECE 517 Fall 2007/wiki3 1 sa

2007-11-19T18:50:26Z

Kkrish: /* C++ */

CSC/ECE 517 Fall 2007/wiki3 1 sa

2007-11-19T18:50:08Z

Kkrish: /* Support for assertions */

CSC/ECE 517 Fall 2007/wiki3 1 sa

2007-11-19T18:49:58Z

Kkrish: /* Support for assertions */

CSC/ECE 517 Fall 2007/wiki3 1 sa

2007-11-19T18:49:43Z

Kkrish:

CSC/ECE 517 Fall 2007/wiki3 1 sa

2007-11-19T18:29:07Z

Kkrish: /* Support for Assertions */

CSC/ECE 517 Fall 2007/wiki3 1 sa

2007-11-19T18:27:51Z

Kkrish: /* Assertions during Developmental Cycles */

CSC/ECE 517 Fall 2007/wiki3 1 sa

2007-11-19T18:27:27Z

Kkrish: /* Types of assertions */

CSC/ECE 517 Fall 2007/wiki3 1 sa

2007-11-19T18:04:03Z

Kkrish: /* Ruby */

CSC/ECE 517 Fall 2007/wiki3 1 sa

2007-11-19T17:45:55Z

Kkrish: /* Types of Assertion */

CSC/ECE 517 Fall 2007/wiki3 1 sa

2007-11-19T17:45:44Z

Kkrish: /* Python */

CSC/ECE 517 Fall 2007/wiki3 1 sa

2007-11-19T17:40:37Z

Kkrish: /* Python */

CSC/ECE 517 Fall 2007/wiki3 1 sa

2007-11-19T17:22:41Z

Kkrish: /* Python */

CSC/ECE 517 Fall 2007/wiki2 9 kk

2007-10-28T06:39:00Z

Kkrish: /* Principle of Least Astonishment */

''Principle of Least Astonishment. Write a guide to the Web pages on the Principle of Least Astonishment. Which should the reader look at for easy-to-understand examples? Which give a feel for where the principle should be used? Is this principle present in fields other than programming? Is the term used consistently in other disciplines?''

= Principle of Least Astonishment =
The principle of least astonishment states that when you are presented with different outcomes, one should always pick the outcome of least ambiguity or surprise. The principle has applications in a lot of fields. This wiki serves as a guide for the reader to understand more about this principle on the web. The principle of least astonishment goes by different names depending on the field of application and is not consistant across all fields with respect to how it is called.

Other names for the principle of least astonishment include:

1. The element of least surprise

2. Occam's Razor

3. The principle of parsimony

4. The principle of minimum suprise

It is important to remember that, when scouring the web for information on the principle of least astonishment, all of the above mentioned terms mean the same.

== Example ==
The simplest example is in programming where the name of a function does not indicate its functionality.

<pre>
int add(int a, int b)
{
return (a*a+b*b);
}
</pre>

The function above is supposed to add two numbers and return the sum but actually returns the sum of squares of the two numbers which would surprise the programmer who is using it.
Applying the principle of least astonishment, we can either rename the function to indicate its functionality or we can rewrite the functionality itself to correspond to its name.

<pre>
int sum_of_squares(int a, int b)
{
return (a*a+b*b);
}
</pre>
or
<pre>
int add(int a, int b)
{
return a+b
}
</pre>

The above example gives a feel for the principle of least astonishment. As this wiki is more about writing a guide to webpages on the principle of least astonishment, the rest of this wiki talks about the applications of this principle, both in programming and in other fields by providing links to other pages on the web.

== Applications in Programming ==

=== General Software Design ===
[http://www.ddj.com/blog/cppblog/archives/2007/10/the_principle_o.html DDJ] has an article which introduces the user to applying the principle of least surprise to general software design by using an example of using arrays in language called APL. A very basic introduction and some examples can also be found [http://c2.com/cgi/wiki?PrincipleOfLeastAstonishment here]. Ken Thompson's [http://www.faqs.org/docs/artu/ch01s06.html Basics of Unix Philosophy] gives a feel for applying the principle of least astonishment in operating system design.

=== API Design ===
The principle of least astonishment also plays an important role in API or library design. For example, when designing libraries or API's we want functions which does what the function name implies it will do. [http://www.atalasoft.com/cs/blogs/stevehawley/archive/2006/02/27/9590.aspx Steven's Tech Talk] has a very good introduction to proper API design using the principle of least astonishment. [http://blogs.sun.com/swinger/entry/simple_kisses_and_surprises Antonio Vierio] looks at what makes an api a good api by applying the principle of least astonishment.

=== User interface design ===
The principle of least astonishment is used a lot in user interface design. [http://www.joelonsoftware.com/uibook/chapters/fog0000000057.html Joel Spolsky] has an article introducing user interface design using the principle of least astonishment. The article looks at a lot of examples of using the element of least surprise by comparing user interface design in Windows and Mac OS X.

A more general introduction to the application of the principle of least astonishment to UI design can be found [http://www.faqs.org/docs/artu/ch11s01.html here].

=== Webpage Design ===
Webpage design like UI design also finds the application of the principle of least astonishment. [http://www.ibm.com/developerworks/web/library/us-cranky10.html IBM] has an excellent article on how this can be done.

== Applications in Other Fields ==
The principle of least astonishment also finds a lot of applications in other fields.

1. Occam's Razor is one of the most popular use of the principle of least astonishment. [http://en.wikipedia.org/wiki/Occam's_razor Occam's Razor] is commonly used to explain phenonmena in such a way that the explanation makes the fewest assumptions possible. In other words, it can be paraphrased as "With all things being equal, the simplest solution tends to be the right one". The [http://skepdic.com/occam.html Skeptic's Dictionary] has a more critical look at this principle. The [http://www.utm.edu/research/iep/o/ockham.htm Internet Encyclopedia of Philosophy] has some interesting applications of Occam's Razor.

2. [http://portal.acm.org/citation.cfm?id=1233682 This] paper looks at applying the principle of least astonishment to the verification of digital circuits.

3. [http://www.mile43.com/peterson/Safety%20First.html This] page looks at applying the principle of least astonishment to riding bicycles in traffic.

4. [http://en.wikipedia.org/wiki/Wikipedia:Guide_to_writing_better_articles#Principle_of_least_astonishment Wikipedia] has some information on applying the principle of least astonishment to writing articles.

== Other Links ==
This section has links which do not fit in with the links already provided in the other sections.

[http://en.wikipedia.org/wiki/Principle_of_least_astonishment Wikipedia entry on the principle of least astonishment]

[http://www.canonical.org/~kragen/tao-of-programming.html#book4 Tao of Programming]

[http://jooto.com/blog/index.php/2006/06/06/principle-of-least-astonishment/ Principle of Least Astonishment in Ruby]

CSC/ECE 517 Fall 2007/wiki2 9 kk

2007-10-28T06:37:37Z

Kkrish: /* Principle of Least Astonishment */

''Principle of Least Astonishment. Write a guide to the Web pages on the Principle of Least Astonishment. Which should the reader look at for easy-to-understand examples? Which give a feel for where the principle should be used? Is this principle present in fields other than programming? Is the term used consistently in other disciplines?''

= Principle of Least Astonishment =
The principle of least astonishment states that when you are presented with different outcomes, one should always pick the outcome of least ambiguity or surprise. The principle has applications in a lot of fields. This wiki serves as a guide for the reader to understand more about this principle on the web. The principle of least astonishment goes by different names depending on the field of application like:

1. The element of least surprise

2. Occam's Razor

3. The principle of parsimony

4. The principle of minimum suprise

It is important to remember that, when scouring the web for information on the principle of least astonishment, all of the above mentioned terms mean the same.

== Example ==
The simplest example is in programming where the name of a function does not indicate its functionality.

<pre>
int add(int a, int b)
{
return (a*a+b*b);
}
</pre>

The function above is supposed to add two numbers and return the sum but actually returns the sum of squares of the two numbers which would surprise the programmer who is using it.
Applying the principle of least astonishment, we can either rename the function to indicate its functionality or we can rewrite the functionality itself to correspond to its name.

<pre>
int sum_of_squares(int a, int b)
{
return (a*a+b*b);
}
</pre>
or
<pre>
int add(int a, int b)
{
return a+b
}
</pre>

The above example gives a feel for the principle of least astonishment. As this wiki is more about writing a guide to webpages on the principle of least astonishment, the rest of this wiki talks about the applications of this principle, both in programming and in other fields by providing links to other pages on the web.

== Applications in Programming ==

=== General Software Design ===
[http://www.ddj.com/blog/cppblog/archives/2007/10/the_principle_o.html DDJ] has an article which introduces the user to applying the principle of least surprise to general software design by using an example of using arrays in language called APL. A very basic introduction and some examples can also be found [http://c2.com/cgi/wiki?PrincipleOfLeastAstonishment here]. Ken Thompson's [http://www.faqs.org/docs/artu/ch01s06.html Basics of Unix Philosophy] gives a feel for applying the principle of least astonishment in operating system design.

=== API Design ===
The principle of least astonishment also plays an important role in API or library design. For example, when designing libraries or API's we want functions which does what the function name implies it will do. [http://www.atalasoft.com/cs/blogs/stevehawley/archive/2006/02/27/9590.aspx Steven's Tech Talk] has a very good introduction to proper API design using the principle of least astonishment. [http://blogs.sun.com/swinger/entry/simple_kisses_and_surprises Antonio Vierio] looks at what makes an api a good api by applying the principle of least astonishment.

=== User interface design ===
The principle of least astonishment is used a lot in user interface design. [http://www.joelonsoftware.com/uibook/chapters/fog0000000057.html Joel Spolsky] has an article introducing user interface design using the principle of least astonishment. The article looks at a lot of examples of using the element of least surprise by comparing user interface design in Windows and Mac OS X.

A more general introduction to the application of the principle of least astonishment to UI design can be found [http://www.faqs.org/docs/artu/ch11s01.html here].

=== Webpage Design ===
Webpage design like UI design also finds the application of the principle of least astonishment. [http://www.ibm.com/developerworks/web/library/us-cranky10.html IBM] has an excellent article on how this can be done.

== Applications in Other Fields ==
The principle of least astonishment also finds a lot of applications in other fields.

1. Occam's Razor is one of the most popular use of the principle of least astonishment. [http://en.wikipedia.org/wiki/Occam's_razor Occam's Razor] is commonly used to explain phenonmena in such a way that the explanation makes the fewest assumptions possible. In other words, it can be paraphrased as "With all things being equal, the simplest solution tends to be the right one". The [http://skepdic.com/occam.html Skeptic's Dictionary] has a more critical look at this principle. The [http://www.utm.edu/research/iep/o/ockham.htm Internet Encyclopedia of Philosophy] has some interesting applications of Occam's Razor.

2. [http://portal.acm.org/citation.cfm?id=1233682 This] paper looks at applying the principle of least astonishment to the verification of digital circuits.

3. [http://www.mile43.com/peterson/Safety%20First.html This] page looks at applying the principle of least astonishment to riding bicycles in traffic.

4. [http://en.wikipedia.org/wiki/Wikipedia:Guide_to_writing_better_articles#Principle_of_least_astonishment Wikipedia] has some information on applying the principle of least astonishment to writing articles.

== Other Links ==
This section has links which do not fit in with the links already provided in the other sections.

[http://en.wikipedia.org/wiki/Principle_of_least_astonishment Wikipedia entry on the principle of least astonishment]

[http://www.canonical.org/~kragen/tao-of-programming.html#book4 Tao of Programming]

[http://jooto.com/blog/index.php/2006/06/06/principle-of-least-astonishment/ Principle of Least Astonishment in Ruby]

CSC/ECE 517 Fall 2007/wiki2 9 kk

2007-10-28T06:34:04Z

Kkrish: /* Principle of Least Astonishment */

''Principle of Least Astonishment. Write a guide to the Web pages on the Principle of Least Astonishment. Which should the reader look at for easy-to-understand examples? Which give a feel for where the principle should be used? Is this principle present in fields other than programming? Is the term used consistently in other disciplines?''

= Principle of Least Astonishment =
The principle of least astonishment states that when you are presented with different outcomes, one should always pick the outcome of least ambiguity or surprise. The principle has applications in a lot of fields. This wiki serves as a guide for the reader to understand more about this principle on the web. The principle of least astonishment goes by different names depending on the field of application like:

1. The element of least surprise

2. Occam's Razor

3. The principle of parsimony

4.

== Example ==
The simplest example is in programming where the name of a function does not indicate its functionality.

<pre>
int add(int a, int b)
{
return (a*a+b*b);
}
</pre>

The function above is supposed to add two numbers and return the sum but actually returns the sum of squares of the two numbers which would surprise the programmer who is using it.
Applying the principle of least astonishment, we can either rename the function to indicate its functionality or we can rewrite the functionality itself to correspond to its name.

<pre>
int sum_of_squares(int a, int b)
{
return (a*a+b*b);
}
</pre>
or
<pre>
int add(int a, int b)
{
return a+b
}
</pre>

The above example gives a feel for the principle of least astonishment. As this wiki is more about writing a guide to webpages on the principle of least astonishment, the rest of this wiki talks about the applications of this principle, both in programming and in other fields by providing links to other pages on the web.

== Applications in Programming ==

=== General Software Design ===
[http://www.ddj.com/blog/cppblog/archives/2007/10/the_principle_o.html DDJ] has an article which introduces the user to applying the principle of least surprise to general software design by using an example of using arrays in language called APL. A very basic introduction and some examples can also be found [http://c2.com/cgi/wiki?PrincipleOfLeastAstonishment here]. Ken Thompson's [http://www.faqs.org/docs/artu/ch01s06.html Basics of Unix Philosophy] gives a feel for applying the principle of least astonishment in operating system design.

=== API Design ===
The principle of least astonishment also plays an important role in API or library design. For example, when designing libraries or API's we want functions which does what the function name implies it will do. [http://www.atalasoft.com/cs/blogs/stevehawley/archive/2006/02/27/9590.aspx Steven's Tech Talk] has a very good introduction to proper API design using the principle of least astonishment. [http://blogs.sun.com/swinger/entry/simple_kisses_and_surprises Antonio Vierio] looks at what makes an api a good api by applying the principle of least astonishment.

=== User interface design ===
The principle of least astonishment is used a lot in user interface design. [http://www.joelonsoftware.com/uibook/chapters/fog0000000057.html Joel Spolsky] has an article introducing user interface design using the principle of least astonishment. The article looks at a lot of examples of using the element of least surprise by comparing user interface design in Windows and Mac OS X.

A more general introduction to the application of the principle of least astonishment to UI design can be found [http://www.faqs.org/docs/artu/ch11s01.html here].

=== Webpage Design ===
Webpage design like UI design also finds the application of the principle of least astonishment. [http://www.ibm.com/developerworks/web/library/us-cranky10.html IBM] has an excellent article on how this can be done.

== Applications in Other Fields ==
The principle of least astonishment also finds a lot of applications in other fields.

1. Occam's Razor is one of the most popular use of the principle of least astonishment. [http://en.wikipedia.org/wiki/Occam's_razor Occam's Razor] is commonly used to explain phenonmena in such a way that the explanation makes the fewest assumptions possible. In other words, it can be paraphrased as "With all things being equal, the simplest solution tends to be the right one". The [http://skepdic.com/occam.html Skeptic's Dictionary] has a more critical look at this principle. The [http://www.utm.edu/research/iep/o/ockham.htm Internet Encyclopedia of Philosophy] has some interesting applications of Occam's Razor.

2. [http://portal.acm.org/citation.cfm?id=1233682 This] paper looks at applying the principle of least astonishment to the verification of digital circuits.

3. [http://www.mile43.com/peterson/Safety%20First.html This] page looks at applying the principle of least astonishment to riding bicycles in traffic.

4. [http://en.wikipedia.org/wiki/Wikipedia:Guide_to_writing_better_articles#Principle_of_least_astonishment Wikipedia] has some information on applying the principle of least astonishment to writing articles.

== Other Links ==
This section has links which do not fit in with the links already provided in the other sections.

[http://en.wikipedia.org/wiki/Principle_of_least_astonishment Wikipedia entry on the principle of least astonishment]

[http://www.canonical.org/~kragen/tao-of-programming.html#book4 Tao of Programming]

[http://jooto.com/blog/index.php/2006/06/06/principle-of-least-astonishment/ Principle of Least Astonishment in Ruby]

CSC/ECE 517 Fall 2007/wiki2 9 kk

2007-10-28T06:33:29Z

Kkrish: /* Principle of Least Astonishment */

''Principle of Least Astonishment. Write a guide to the Web pages on the Principle of Least Astonishment. Which should the reader look at for easy-to-understand examples? Which give a feel for where the principle should be used? Is this principle present in fields other than programming? Is the term used consistently in other disciplines?''

= Principle of Least Astonishment =
The principle of least astonishment states that when you are presented with different outcomes, one should always pick the outcome of least ambiguity or surprise. The principle has applications in a lot of fields. This wiki serves as a guide for the reader to understand more about this principle on the web. The principle of least astonishment goes by different names depending on the field of application like

1. The element of least surprise

2. Occam's Razor

3. The principle of parsimony

== Example ==
The simplest example is in programming where the name of a function does not indicate its functionality.

<pre>
int add(int a, int b)
{
return (a*a+b*b);
}
</pre>

The function above is supposed to add two numbers and return the sum but actually returns the sum of squares of the two numbers which would surprise the programmer who is using it.
Applying the principle of least astonishment, we can either rename the function to indicate its functionality or we can rewrite the functionality itself to correspond to its name.

<pre>
int sum_of_squares(int a, int b)
{
return (a*a+b*b);
}
</pre>
or
<pre>
int add(int a, int b)
{
return a+b
}
</pre>

The above example gives a feel for the principle of least astonishment. As this wiki is more about writing a guide to webpages on the principle of least astonishment, the rest of this wiki talks about the applications of this principle, both in programming and in other fields by providing links to other pages on the web.

== Applications in Programming ==

=== General Software Design ===
[http://www.ddj.com/blog/cppblog/archives/2007/10/the_principle_o.html DDJ] has an article which introduces the user to applying the principle of least surprise to general software design by using an example of using arrays in language called APL. A very basic introduction and some examples can also be found [http://c2.com/cgi/wiki?PrincipleOfLeastAstonishment here]. Ken Thompson's [http://www.faqs.org/docs/artu/ch01s06.html Basics of Unix Philosophy] gives a feel for applying the principle of least astonishment in operating system design.

=== API Design ===
The principle of least astonishment also plays an important role in API or library design. For example, when designing libraries or API's we want functions which does what the function name implies it will do. [http://www.atalasoft.com/cs/blogs/stevehawley/archive/2006/02/27/9590.aspx Steven's Tech Talk] has a very good introduction to proper API design using the principle of least astonishment. [http://blogs.sun.com/swinger/entry/simple_kisses_and_surprises Antonio Vierio] looks at what makes an api a good api by applying the principle of least astonishment.

=== User interface design ===
The principle of least astonishment is used a lot in user interface design. [http://www.joelonsoftware.com/uibook/chapters/fog0000000057.html Joel Spolsky] has an article introducing user interface design using the principle of least astonishment. The article looks at a lot of examples of using the element of least surprise by comparing user interface design in Windows and Mac OS X.

A more general introduction to the application of the principle of least astonishment to UI design can be found [http://www.faqs.org/docs/artu/ch11s01.html here].

=== Webpage Design ===
Webpage design like UI design also finds the application of the principle of least astonishment. [http://www.ibm.com/developerworks/web/library/us-cranky10.html IBM] has an excellent article on how this can be done.

== Applications in Other Fields ==
The principle of least astonishment also finds a lot of applications in other fields.

1. Occam's Razor is one of the most popular use of the principle of least astonishment. [http://en.wikipedia.org/wiki/Occam's_razor Occam's Razor] is commonly used to explain phenonmena in such a way that the explanation makes the fewest assumptions possible. In other words, it can be paraphrased as "With all things being equal, the simplest solution tends to be the right one". The [http://skepdic.com/occam.html Skeptic's Dictionary] has a more critical look at this principle. The [http://www.utm.edu/research/iep/o/ockham.htm Internet Encyclopedia of Philosophy] has some interesting applications of Occam's Razor.

2. [http://portal.acm.org/citation.cfm?id=1233682 This] paper looks at applying the principle of least astonishment to the verification of digital circuits.

3. [http://www.mile43.com/peterson/Safety%20First.html This] page looks at applying the principle of least astonishment to riding bicycles in traffic.

4. [http://en.wikipedia.org/wiki/Wikipedia:Guide_to_writing_better_articles#Principle_of_least_astonishment Wikipedia] has some information on applying the principle of least astonishment to writing articles.

== Other Links ==
This section has links which do not fit in with the links already provided in the other sections.

[http://en.wikipedia.org/wiki/Principle_of_least_astonishment Wikipedia entry on the principle of least astonishment]

[http://www.canonical.org/~kragen/tao-of-programming.html#book4 Tao of Programming]

[http://jooto.com/blog/index.php/2006/06/06/principle-of-least-astonishment/ Principle of Least Astonishment in Ruby]

CSC/ECE 517 Fall 2007/wiki2 9 kk

2007-10-28T06:29:50Z

Kkrish: /* Other External Links */

''Principle of Least Astonishment. Write a guide to the Web pages on the Principle of Least Astonishment. Which should the reader look at for easy-to-understand examples? Which give a feel for where the principle should be used? Is this principle present in fields other than programming? Is the term used consistently in other disciplines?''

= Principle of Least Astonishment =
The principle of least astonishment states that when you are presented with different outcomes, one should always pick the outcome of least ambiguity or surprise. The principle has applications in a lot of fields. This wiki serves as a guide for the reader to understand more about this principle on the web. The principle of least astonishment goes by different names depending on the field of application like the element of least surprise, Occam's Razor etc.

== Example ==
The simplest example is in programming where the name of a function does not indicate its functionality.

<pre>
int add(int a, int b)
{
return (a*a+b*b);
}
</pre>

The function above is supposed to add two numbers and return the sum but actually returns the sum of squares of the two numbers which would surprise the programmer who is using it.
Applying the principle of least astonishment, we can either rename the function to indicate its functionality or we can rewrite the functionality itself to correspond to its name.

<pre>
int sum_of_squares(int a, int b)
{
return (a*a+b*b);
}
</pre>
or
<pre>
int add(int a, int b)
{
return a+b
}
</pre>

The above example gives a feel for the principle of least astonishment. As this wiki is more about writing a guide to webpages on the principle of least astonishment, the rest of this wiki talks about the applications of this principle, both in programming and in other fields by providing links to other pages on the web.

== Applications in Programming ==

=== General Software Design ===
[http://www.ddj.com/blog/cppblog/archives/2007/10/the_principle_o.html DDJ] has an article which introduces the user to applying the principle of least surprise to general software design by using an example of using arrays in language called APL. A very basic introduction and some examples can also be found [http://c2.com/cgi/wiki?PrincipleOfLeastAstonishment here]. Ken Thompson's [http://www.faqs.org/docs/artu/ch01s06.html Basics of Unix Philosophy] gives a feel for applying the principle of least astonishment in operating system design.

=== API Design ===
The principle of least astonishment also plays an important role in API or library design. For example, when designing libraries or API's we want functions which does what the function name implies it will do. [http://www.atalasoft.com/cs/blogs/stevehawley/archive/2006/02/27/9590.aspx Steven's Tech Talk] has a very good introduction to proper API design using the principle of least astonishment. [http://blogs.sun.com/swinger/entry/simple_kisses_and_surprises Antonio Vierio] looks at what makes an api a good api by applying the principle of least astonishment.

=== User interface design ===
The principle of least astonishment is used a lot in user interface design. [http://www.joelonsoftware.com/uibook/chapters/fog0000000057.html Joel Spolsky] has an article introducing user interface design using the principle of least astonishment. The article looks at a lot of examples of using the element of least surprise by comparing user interface design in Windows and Mac OS X.

A more general introduction to the application of the principle of least astonishment to UI design can be found [http://www.faqs.org/docs/artu/ch11s01.html here].

=== Webpage Design ===
Webpage design like UI design also finds the application of the principle of least astonishment. [http://www.ibm.com/developerworks/web/library/us-cranky10.html IBM] has an excellent article on how this can be done.

== Applications in Other Fields ==
The principle of least astonishment also finds a lot of applications in other fields.

1. Occam's Razor is one of the most popular use of the principle of least astonishment. [http://en.wikipedia.org/wiki/Occam's_razor Occam's Razor] is commonly used to explain phenonmena in such a way that the explanation makes the fewest assumptions possible. In other words, it can be paraphrased as "With all things being equal, the simplest solution tends to be the right one". The [http://skepdic.com/occam.html Skeptic's Dictionary] has a more critical look at this principle. The [http://www.utm.edu/research/iep/o/ockham.htm Internet Encyclopedia of Philosophy] has some interesting applications of Occam's Razor.

2. [http://portal.acm.org/citation.cfm?id=1233682 This] paper looks at applying the principle of least astonishment to the verification of digital circuits.

3. [http://www.mile43.com/peterson/Safety%20First.html This] page looks at applying the principle of least astonishment to riding bicycles in traffic.

4. [http://en.wikipedia.org/wiki/Wikipedia:Guide_to_writing_better_articles#Principle_of_least_astonishment Wikipedia] has some information on applying the principle of least astonishment to writing articles.

== Other Links ==
This section has links which do not fit in with the links already provided in the other sections.

[http://en.wikipedia.org/wiki/Principle_of_least_astonishment Wikipedia entry on the principle of least astonishment]

[http://www.canonical.org/~kragen/tao-of-programming.html#book4 Tao of Programming]

[http://jooto.com/blog/index.php/2006/06/06/principle-of-least-astonishment/ Principle of Least Astonishment in Ruby]

CSC/ECE 517 Fall 2007/wiki2 9 kk

2007-10-28T06:29:07Z

Kkrish: /* General Software Design */

''Principle of Least Astonishment. Write a guide to the Web pages on the Principle of Least Astonishment. Which should the reader look at for easy-to-understand examples? Which give a feel for where the principle should be used? Is this principle present in fields other than programming? Is the term used consistently in other disciplines?''

= Principle of Least Astonishment =
The principle of least astonishment states that when you are presented with different outcomes, one should always pick the outcome of least ambiguity or surprise. The principle has applications in a lot of fields. This wiki serves as a guide for the reader to understand more about this principle on the web. The principle of least astonishment goes by different names depending on the field of application like the element of least surprise, Occam's Razor etc.

== Example ==
The simplest example is in programming where the name of a function does not indicate its functionality.

<pre>
int add(int a, int b)
{
return (a*a+b*b);
}
</pre>

The function above is supposed to add two numbers and return the sum but actually returns the sum of squares of the two numbers which would surprise the programmer who is using it.
Applying the principle of least astonishment, we can either rename the function to indicate its functionality or we can rewrite the functionality itself to correspond to its name.

<pre>
int sum_of_squares(int a, int b)
{
return (a*a+b*b);
}
</pre>
or
<pre>
int add(int a, int b)
{
return a+b
}
</pre>

The above example gives a feel for the principle of least astonishment. As this wiki is more about writing a guide to webpages on the principle of least astonishment, the rest of this wiki talks about the applications of this principle, both in programming and in other fields by providing links to other pages on the web.

== Applications in Programming ==

=== General Software Design ===
[http://www.ddj.com/blog/cppblog/archives/2007/10/the_principle_o.html DDJ] has an article which introduces the user to applying the principle of least surprise to general software design by using an example of using arrays in language called APL. A very basic introduction and some examples can also be found [http://c2.com/cgi/wiki?PrincipleOfLeastAstonishment here]. Ken Thompson's [http://www.faqs.org/docs/artu/ch01s06.html Basics of Unix Philosophy] gives a feel for applying the principle of least astonishment in operating system design.

=== API Design ===
The principle of least astonishment also plays an important role in API or library design. For example, when designing libraries or API's we want functions which does what the function name implies it will do. [http://www.atalasoft.com/cs/blogs/stevehawley/archive/2006/02/27/9590.aspx Steven's Tech Talk] has a very good introduction to proper API design using the principle of least astonishment. [http://blogs.sun.com/swinger/entry/simple_kisses_and_surprises Antonio Vierio] looks at what makes an api a good api by applying the principle of least astonishment.

=== User interface design ===
The principle of least astonishment is used a lot in user interface design. [http://www.joelonsoftware.com/uibook/chapters/fog0000000057.html Joel Spolsky] has an article introducing user interface design using the principle of least astonishment. The article looks at a lot of examples of using the element of least surprise by comparing user interface design in Windows and Mac OS X.

A more general introduction to the application of the principle of least astonishment to UI design can be found [http://www.faqs.org/docs/artu/ch11s01.html here].

=== Webpage Design ===
Webpage design like UI design also finds the application of the principle of least astonishment. [http://www.ibm.com/developerworks/web/library/us-cranky10.html IBM] has an excellent article on how this can be done.

== Applications in Other Fields ==
The principle of least astonishment also finds a lot of applications in other fields.

1. Occam's Razor is one of the most popular use of the principle of least astonishment. [http://en.wikipedia.org/wiki/Occam's_razor Occam's Razor] is commonly used to explain phenonmena in such a way that the explanation makes the fewest assumptions possible. In other words, it can be paraphrased as "With all things being equal, the simplest solution tends to be the right one". The [http://skepdic.com/occam.html Skeptic's Dictionary] has a more critical look at this principle. The [http://www.utm.edu/research/iep/o/ockham.htm Internet Encyclopedia of Philosophy] has some interesting applications of Occam's Razor.

2. [http://portal.acm.org/citation.cfm?id=1233682 This] paper looks at applying the principle of least astonishment to the verification of digital circuits.

3. [http://www.mile43.com/peterson/Safety%20First.html This] page looks at applying the principle of least astonishment to riding bicycles in traffic.

4. [http://en.wikipedia.org/wiki/Wikipedia:Guide_to_writing_better_articles#Principle_of_least_astonishment Wikipedia] has some information on applying the principle of least astonishment to writing articles.

== Other External Links ==
This section has links which do not fit in with the links already provided in the other sections.

[http://en.wikipedia.org/wiki/Principle_of_least_astonishment Wikipedia entry on the principle of least astonishment]

[http://www.canonical.org/~kragen/tao-of-programming.html#book4 Tao of Programming]

[http://jooto.com/blog/index.php/2006/06/06/principle-of-least-astonishment/ Principle of Least Astonishment in Ruby]

CSC/ECE 517 Fall 2007/wiki2 9 kk

2007-10-28T06:28:48Z

Kkrish: /* General Software Design */

''Principle of Least Astonishment. Write a guide to the Web pages on the Principle of Least Astonishment. Which should the reader look at for easy-to-understand examples? Which give a feel for where the principle should be used? Is this principle present in fields other than programming? Is the term used consistently in other disciplines?''

= Principle of Least Astonishment =
The principle of least astonishment states that when you are presented with different outcomes, one should always pick the outcome of least ambiguity or surprise. The principle has applications in a lot of fields. This wiki serves as a guide for the reader to understand more about this principle on the web. The principle of least astonishment goes by different names depending on the field of application like the element of least surprise, Occam's Razor etc.

== Example ==
The simplest example is in programming where the name of a function does not indicate its functionality.

<pre>
int add(int a, int b)
{
return (a*a+b*b);
}
</pre>

The function above is supposed to add two numbers and return the sum but actually returns the sum of squares of the two numbers which would surprise the programmer who is using it.
Applying the principle of least astonishment, we can either rename the function to indicate its functionality or we can rewrite the functionality itself to correspond to its name.

<pre>
int sum_of_squares(int a, int b)
{
return (a*a+b*b);
}
</pre>
or
<pre>
int add(int a, int b)
{
return a+b
}
</pre>

The above example gives a feel for the principle of least astonishment. As this wiki is more about writing a guide to webpages on the principle of least astonishment, the rest of this wiki talks about the applications of this principle, both in programming and in other fields by providing links to other pages on the web.

== Applications in Programming ==

=== General Software Design ===
[http://www.ddj.com/blog/cppblog/archives/2007/10/the_principle_o.html DDJ] has an article which introduces the user to applying the principle of least surprise to general software design by using an example of using arrays in language called APL. A very basic introduction and some examples can also be found [http://c2.com/cgi/wiki?PrincipleOfLeastAstonishment here].
Ken Thompson's [http://www.faqs.org/docs/artu/ch01s06.html Basics of Unix Philosophy] gives a feel for applying the principle of least astonishment in operating system design.

=== API Design ===
The principle of least astonishment also plays an important role in API or library design. For example, when designing libraries or API's we want functions which does what the function name implies it will do. [http://www.atalasoft.com/cs/blogs/stevehawley/archive/2006/02/27/9590.aspx Steven's Tech Talk] has a very good introduction to proper API design using the principle of least astonishment. [http://blogs.sun.com/swinger/entry/simple_kisses_and_surprises Antonio Vierio] looks at what makes an api a good api by applying the principle of least astonishment.

=== User interface design ===
The principle of least astonishment is used a lot in user interface design. [http://www.joelonsoftware.com/uibook/chapters/fog0000000057.html Joel Spolsky] has an article introducing user interface design using the principle of least astonishment. The article looks at a lot of examples of using the element of least surprise by comparing user interface design in Windows and Mac OS X.

A more general introduction to the application of the principle of least astonishment to UI design can be found [http://www.faqs.org/docs/artu/ch11s01.html here].

=== Webpage Design ===
Webpage design like UI design also finds the application of the principle of least astonishment. [http://www.ibm.com/developerworks/web/library/us-cranky10.html IBM] has an excellent article on how this can be done.

== Applications in Other Fields ==
The principle of least astonishment also finds a lot of applications in other fields.

1. Occam's Razor is one of the most popular use of the principle of least astonishment. [http://en.wikipedia.org/wiki/Occam's_razor Occam's Razor] is commonly used to explain phenonmena in such a way that the explanation makes the fewest assumptions possible. In other words, it can be paraphrased as "With all things being equal, the simplest solution tends to be the right one". The [http://skepdic.com/occam.html Skeptic's Dictionary] has a more critical look at this principle. The [http://www.utm.edu/research/iep/o/ockham.htm Internet Encyclopedia of Philosophy] has some interesting applications of Occam's Razor.

2. [http://portal.acm.org/citation.cfm?id=1233682 This] paper looks at applying the principle of least astonishment to the verification of digital circuits.

3. [http://www.mile43.com/peterson/Safety%20First.html This] page looks at applying the principle of least astonishment to riding bicycles in traffic.

4. [http://en.wikipedia.org/wiki/Wikipedia:Guide_to_writing_better_articles#Principle_of_least_astonishment Wikipedia] has some information on applying the principle of least astonishment to writing articles.

== Other External Links ==
This section has links which do not fit in with the links already provided in the other sections.

[http://en.wikipedia.org/wiki/Principle_of_least_astonishment Wikipedia entry on the principle of least astonishment]

[http://www.canonical.org/~kragen/tao-of-programming.html#book4 Tao of Programming]

[http://jooto.com/blog/index.php/2006/06/06/principle-of-least-astonishment/ Principle of Least Astonishment in Ruby]

CSC/ECE 517 Fall 2007/wiki2 9 kk

2007-10-28T06:21:56Z

Kkrish: /* Example */

''Principle of Least Astonishment. Write a guide to the Web pages on the Principle of Least Astonishment. Which should the reader look at for easy-to-understand examples? Which give a feel for where the principle should be used? Is this principle present in fields other than programming? Is the term used consistently in other disciplines?''

= Principle of Least Astonishment =
The principle of least astonishment states that when you are presented with different outcomes, one should always pick the outcome of least ambiguity or surprise. The principle has applications in a lot of fields. This wiki serves as a guide for the reader to understand more about this principle on the web. The principle of least astonishment goes by different names depending on the field of application like the element of least surprise, Occam's Razor etc.

== Example ==
The simplest example is in programming where the name of a function does not indicate its functionality.

<pre>
int add(int a, int b)
{
return (a*a+b*b);
}
</pre>

The function above is supposed to add two numbers and return the sum but actually returns the sum of squares of the two numbers which would surprise the programmer who is using it.
Applying the principle of least astonishment, we can either rename the function to indicate its functionality or we can rewrite the functionality itself to correspond to its name.

<pre>
int sum_of_squares(int a, int b)
{
return (a*a+b*b);
}
</pre>
or
<pre>
int add(int a, int b)
{
return a+b
}
</pre>

The above example gives a feel for the principle of least astonishment. As this wiki is more about writing a guide to webpages on the principle of least astonishment, the rest of this wiki talks about the applications of this principle, both in programming and in other fields by providing links to other pages on the web.

== Applications in Programming ==

=== General Software Design ===
[http://www.ddj.com/blog/cppblog/archives/2007/10/the_principle_o.html DDJ] has an article which introduces the user to applying the principle of least surprise to general software design by using an example of using arrays in language called APL. A very basic introduction and some examples can also be found [http://c2.com/cgi/wiki?PrincipleOfLeastAstonishment here].

=== API Design ===
The principle of least astonishment also plays an important role in API or library design. For example, when designing libraries or API's we want functions which does what the function name implies it will do. [http://www.atalasoft.com/cs/blogs/stevehawley/archive/2006/02/27/9590.aspx Steven's Tech Talk] has a very good introduction to proper API design using the principle of least astonishment. [http://blogs.sun.com/swinger/entry/simple_kisses_and_surprises Antonio Vierio] looks at what makes an api a good api by applying the principle of least astonishment.

=== User interface design ===
The principle of least astonishment is used a lot in user interface design. [http://www.joelonsoftware.com/uibook/chapters/fog0000000057.html Joel Spolsky] has an article introducing user interface design using the principle of least astonishment. The article looks at a lot of examples of using the element of least surprise by comparing user interface design in Windows and Mac OS X.

A more general introduction to the application of the principle of least astonishment to UI design can be found [http://www.faqs.org/docs/artu/ch11s01.html here].

=== Webpage Design ===
Webpage design like UI design also finds the application of the principle of least astonishment. [http://www.ibm.com/developerworks/web/library/us-cranky10.html IBM] has an excellent article on how this can be done.

== Applications in Other Fields ==
The principle of least astonishment also finds a lot of applications in other fields.

1. Occam's Razor is one of the most popular use of the principle of least astonishment. [http://en.wikipedia.org/wiki/Occam's_razor Occam's Razor] is commonly used to explain phenonmena in such a way that the explanation makes the fewest assumptions possible. In other words, it can be paraphrased as "With all things being equal, the simplest solution tends to be the right one". The [http://skepdic.com/occam.html Skeptic's Dictionary] has a more critical look at this principle. The [http://www.utm.edu/research/iep/o/ockham.htm Internet Encyclopedia of Philosophy] has some interesting applications of Occam's Razor.

2. [http://portal.acm.org/citation.cfm?id=1233682 This] paper looks at applying the principle of least astonishment to the verification of digital circuits.

3. [http://www.mile43.com/peterson/Safety%20First.html This] page looks at applying the principle of least astonishment to riding bicycles in traffic.

4. [http://en.wikipedia.org/wiki/Wikipedia:Guide_to_writing_better_articles#Principle_of_least_astonishment Wikipedia] has some information on applying the principle of least astonishment to writing articles.

== Other External Links ==
This section has links which do not fit in with the links already provided in the other sections.

[http://en.wikipedia.org/wiki/Principle_of_least_astonishment Wikipedia entry on the principle of least astonishment]

[http://www.canonical.org/~kragen/tao-of-programming.html#book4 Tao of Programming]

[http://jooto.com/blog/index.php/2006/06/06/principle-of-least-astonishment/ Principle of Least Astonishment in Ruby]

CSC/ECE 517 Fall 2007/wiki2 9 kk

2007-10-28T06:21:05Z

Kkrish: /* Applications in Other Fields */

''Principle of Least Astonishment. Write a guide to the Web pages on the Principle of Least Astonishment. Which should the reader look at for easy-to-understand examples? Which give a feel for where the principle should be used? Is this principle present in fields other than programming? Is the term used consistently in other disciplines?''

= Principle of Least Astonishment =
The principle of least astonishment states that when you are presented with different outcomes, one should always pick the outcome of least ambiguity or surprise. The principle has applications in a lot of fields. This wiki serves as a guide for the reader to understand more about this principle on the web. The principle of least astonishment goes by different names depending on the field of application like the element of least surprise, Occam's Razor etc.

== Example ==
The simplest example is in programming where the name of a function does not indicate its functionality.

<pre>
int add(int a, int b)
{
return (a*a+b*b);
}
</pre>

The function above is supposed to add two numbers and return the sum but actually returns the sum of squares of the two numbers which would surprise the programmer who is using it.
Applying the principle of least astonishment, we can either rename the function to indicate its functionality or we can rewrite the functionality itself to correspond to its name.

<pre>
int sum_of_squares(int a, int b)
{
return (a*a+b*b);
}
</pre>
or
<pre>
int add(int a, int b)
{
return a+b
}
</pre>

The above example gives a feel for the principle of least astonishment. As this wiki is more about writing a guide to webpages on the principle of least astonishment, the next section talks about the applications of this principle, both in programming and in other fields by providing links to other pages on the web.

== Applications in Programming ==

=== General Software Design ===
[http://www.ddj.com/blog/cppblog/archives/2007/10/the_principle_o.html DDJ] has an article which introduces the user to applying the principle of least surprise to general software design by using an example of using arrays in language called APL. A very basic introduction and some examples can also be found [http://c2.com/cgi/wiki?PrincipleOfLeastAstonishment here].

=== API Design ===
The principle of least astonishment also plays an important role in API or library design. For example, when designing libraries or API's we want functions which does what the function name implies it will do. [http://www.atalasoft.com/cs/blogs/stevehawley/archive/2006/02/27/9590.aspx Steven's Tech Talk] has a very good introduction to proper API design using the principle of least astonishment. [http://blogs.sun.com/swinger/entry/simple_kisses_and_surprises Antonio Vierio] looks at what makes an api a good api by applying the principle of least astonishment.

=== User interface design ===
The principle of least astonishment is used a lot in user interface design. [http://www.joelonsoftware.com/uibook/chapters/fog0000000057.html Joel Spolsky] has an article introducing user interface design using the principle of least astonishment. The article looks at a lot of examples of using the element of least surprise by comparing user interface design in Windows and Mac OS X.

A more general introduction to the application of the principle of least astonishment to UI design can be found [http://www.faqs.org/docs/artu/ch11s01.html here].

=== Webpage Design ===
Webpage design like UI design also finds the application of the principle of least astonishment. [http://www.ibm.com/developerworks/web/library/us-cranky10.html IBM] has an excellent article on how this can be done.

== Applications in Other Fields ==
The principle of least astonishment also finds a lot of applications in other fields.

1. Occam's Razor is one of the most popular use of the principle of least astonishment. [http://en.wikipedia.org/wiki/Occam's_razor Occam's Razor] is commonly used to explain phenonmena in such a way that the explanation makes the fewest assumptions possible. In other words, it can be paraphrased as "With all things being equal, the simplest solution tends to be the right one". The [http://skepdic.com/occam.html Skeptic's Dictionary] has a more critical look at this principle. The [http://www.utm.edu/research/iep/o/ockham.htm Internet Encyclopedia of Philosophy] has some interesting applications of Occam's Razor.

2. [http://portal.acm.org/citation.cfm?id=1233682 This] paper looks at applying the principle of least astonishment to the verification of digital circuits.

3. [http://www.mile43.com/peterson/Safety%20First.html This] page looks at applying the principle of least astonishment to riding bicycles in traffic.

4. [http://en.wikipedia.org/wiki/Wikipedia:Guide_to_writing_better_articles#Principle_of_least_astonishment Wikipedia] has some information on applying the principle of least astonishment to writing articles.

== Other External Links ==
This section has links which do not fit in with the links already provided in the other sections.

[http://en.wikipedia.org/wiki/Principle_of_least_astonishment Wikipedia entry on the principle of least astonishment]

[http://www.canonical.org/~kragen/tao-of-programming.html#book4 Tao of Programming]

[http://jooto.com/blog/index.php/2006/06/06/principle-of-least-astonishment/ Principle of Least Astonishment in Ruby]