CSC/ECE 517 Fall 2007/wiki3 1 sa: Difference between revisions
(55 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
'''Support for | '''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 | ''Topic :Compare the support for assertions in various o-o programming languages. How well is it integrated with the language (instead of being supplied by libraries)? How many kinds of assertions are supported? How are assertions used in the various flavors of xUnit testing frameworks? '' | ||
=Introduction= | =Introduction= | ||
Line 28: | Line 28: | ||
==Usage== | ==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 | * 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. | *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 | *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] | * Static assertions: Assertions that are checked at compile time are called static assertions.[1] | ||
=Support for assertions in various o-o programming languages= | =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 | 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''' | '''1. How well the support for assertions is integrated with the language''' | ||
Line 60: | Line 60: | ||
Java supports runtime assertions since it is a statically typed language. It also allows specifying the pre-condition and post-condition, internal invariant type of assertions. | Java supports runtime assertions since it is a statically typed language. It also allows specifying the pre-condition and post-condition, internal invariant type of assertions. | ||
A very simple | A very simple switch-case example can be formulated as follows where an assertion is used for the default case where the assert false statement is executed when none of the case statements are true. | ||
switch(color) { | switch(color) { | ||
Line 80: | Line 80: | ||
==C++== | ==C++== | ||
===Support for assertions=== | ===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''. | 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=== | ===Types of assertions=== | ||
Line 98: | Line 98: | ||
</pre> | </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 ==== | ==== Assertions during Developmental Cycles ==== | ||
The ''assert'' macro is defined only if ''NDEBUG'' is not defined. Therefore, a programmer can define 'NDEBUG' using a ''#define NDEBUG'' during the release cycle to remove all assertions in the code. There is no performance penalty in this case. | The ''assert'' macro is defined only if ''NDEBUG'' is not defined. Therefore, a programmer can define ''NDEBUG'' using a ''#define NDEBUG'' during the release cycle to remove all assertions in the code. There is no performance penalty in this case as the preprocessor will remove all the debugging code. | ||
==== Assertions in Design by Contract ==== | ==== Assertions in Design by Contract ==== | ||
Assertions in Design by Contract are supported in C++ using third party tools such as the DBC for C preprocessor, GNU Nana, C², or the Digital Mars C++ compiler. | Assertions in Design by Contract are supported in C++ using third party tools such as the DBC for C preprocessor, GNU Nana, C², or the Digital Mars C++ compiler. | ||
==== Assertions in xUnit ==== | |||
In C++, there is no one standardized framework but it does have several testing frameworks with different APIs. A list of these can be found [http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks#C.2B.2B here]. Most of them are ports of JUnit to C++. Since, assertions are not native to C++, each testing unit defines its own assert macros and functions. In the example listed above the ''assert.h'' standard library provides the ''assert()'' function. If the testing framework is ''CPPUnit'', then the corresponding assert function is ''CPPUNIT_ASSERT(expression)''. | |||
==Ruby== | ==Ruby== | ||
===Support for Assertions=== | ===Support for Assertions=== | ||
Ruby does not have native support for assertions. Assertions are supported using the ''Test::Unit'' framework. ''Test::Unit::Assertions '' contain the standard Test::Unit assertions. Please refer to the [http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit.html Official Ruby Documentation] for more information on using the ''Test::Unit'' framework. | Ruby does not have native support for assertions. Assertions are supported using the ''Test::Unit'' framework. ''Test::Unit::Assertions '' contain the standard Test::Unit assertions. Please refer to the [http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit.html Official Ruby Documentation] for more information on using the ''Test::Unit'' framework. An assertion failure will result in the exception ''AssertionFailedError'' being thrown with the pertinent information on where the assertion failed which, if required, can be ''rescued'' by the programmer. | ||
===Types of assertions=== | ===Types of assertions=== | ||
Line 130: | Line 133: | ||
==== Assertions during Developmental Cycle ==== | ==== Assertions during Developmental Cycle ==== | ||
Since, Ruby does not have native support for assertions there is no way to turn off assertions during runtime unless the programmer explicitly does so. | Since, Ruby does not have native support for assertions there is no way to turn off assertions during runtime unless the programmer explicitly does so.However, since assertions in Ruby are part of the unit testing framework, they are expected to be used only in the test fixture and not in the actual development code. | ||
==== Assertions in Design by Contract ==== | ==== Assertions in Design by Contract ==== | ||
Ruby | Ruby supports assertions in Design by Contract using third party libraries like Brian McCallister's DesignByContract, Ruby DBC or ruby-contract. | ||
==== Assertions in xUnit ==== | |||
Ruby uses the ''Test::Unit'' framework for unit testing and the ''Test::Unit::Assertions'' provides the necessary assertion support. Some of the commonly used assert statements in Ruby are ''assert(), assert_equal(), assert_not_equal(), assert_nil(), assert_not_nil(), assert_same(), assert_not_same()''. | |||
==Python== | ==Python== | ||
=== Support for Assertions === | === Support for Assertions === | ||
Assertions in Python are built into the language and are implemented using the ''assert'' statement. The syntax for the ''assert'' statement is as follows: | Assertions in Python are built into the language and are implemented using the ''assert'' statement. The syntax for the ''assert'' statement according to the official Python documentation is as follows: | ||
assert_stmt::="assert" expression ["," expression] | assert_stmt::="assert" expression ["," expression] | ||
The second expression is optional. Please refer to [http://docs.python.org/ref/assert.html Python Documentation] for more information on the ''assert'' statement syntax. | The second expression is optional. Please refer to [http://docs.python.org/ref/assert.html Python Documentation] for more information on the ''assert'' statement syntax. The exception ''AssertionError'' is thrown whenever an assertion fails and will usually result in the termination of the program. | ||
=== Types of Assertions === | === Types of Assertions === | ||
Line 150: | Line 156: | ||
assert x>0 #will be true as long as x>0 | assert x>0 #will be true as long as x>0 | ||
In the example above, the expression ''x>0'' will evaluate to ''true'' and therefore, no ''AssertionError'' is raised. | |||
The ''assert'' statement can also be used for type checking since python is a dynamically typed language. This is useful in making sure the type of the arguments to an function are correct. | The ''assert'' statement can also be used for type checking since python is a dynamically typed language. This is useful in making sure the type of the arguments to an function are correct. | ||
Line 160: | Line 166: | ||
assert type(name) is StringType, "name is not String: %s" % `name` | assert type(name) is StringType, "name is not String: %s" % `name` | ||
The string expression at the end of the ''assert statement'' is printed out only if the assertion fails. | The string expression at the end of the ''assert statement'' is printed out only if the assertion fails. | ||
==== Assertions during Developmental Cycle ==== | ==== Assertions during Developmental Cycle ==== | ||
Assertions in | Assertions in Python are executed only in debug mode and can be disabled by passing the "-O" option to the python interpreter. This allows the developer to turn off assertions in the release builds to avoid unnecessary performance slowdowns. | ||
==== Assertions in Design by Contract ==== | ==== Assertions in Design by Contract ==== | ||
Python does not have native support for assertions in Design by Contract(DBC). However, there are third party libraries like PyDBC or Contracts for Python which add support for DBC. | Python does not have native support for assertions in Design by Contract(DBC). However, there are third party libraries like PyDBC or Contracts for Python which add support for DBC. | ||
==== Assertions in xUnit ==== | |||
The standard Unit testing framework in Python is [http://pyunit.sourceforge.net/ PyUnit]. It is a part of the Python standard library. PyUnit is based on the JUnit framework. The pyUnit framework uses the built-in Python ''assert'' statement for assertions. | |||
==Eiffel== | ==Eiffel== | ||
===Support for assertions=== | ===Support for assertions=== | ||
Eiffel has native support for assertions through Design by Contract. | Eiffel has native support for assertions through Design by Contract. Here, the state of the code to be executed before and after execution is explicitly defined using pre-conditions and post-conditions. These conditions are also extracted and included in the documentation of the class which ensures that the documentation stays in sync with the code. | ||
===Types of assertions=== | ===Types of assertions=== | ||
====Design by Contract==== | ====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/] | 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> | <pre> | ||
Line 192: | Line 202: | ||
</pre> | </pre> | ||
=xUnit testing frameworks | ==== 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= | =References= | ||
Line 207: | Line 217: | ||
=External Links= | =External Links= | ||
[http://wiki.python.org/moin/UsingAssertionsEffectively Assertions in Python] | *[http://wiki.python.org/moin/UsingAssertionsEffectively Assertions in Python] | ||
*[http://docs.python.org/ref/assert.html Assert statement 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://en.wikibooks.org/wiki/Ruby_Programming/Unit_testing Unit Testing 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://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/Assertions.html Assertions in Ruby] | *[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://archive.eiffel.com/doc/manuals/technology/contract/ Design by Contract in Eiffel] | *[http://www.junit.org/ JUnit] | ||
*[http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks#C.2B.2B Unit testing in C++] | |||
[http://en.wikipedia.org/wiki/Design_by_contract Design by Contract] | *[http://pyunit.sourceforge.net/ PyUnit]. | ||
[http://wiki.rubyonrails.org/rails/pages/HowtoUnitTest More information on Ruby Unit Testing] | |||
[http:// | =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] | |||
== |
Latest revision as of 20:39, 28 November 2007
Support for Assertions in Various O-O Programming Languages
Topic :Compare the support for assertions in various o-o programming languages. How well is it integrated with the language (instead of being supplied by libraries)? How many kinds of assertions are supported? How are assertions used in the various flavors of xUnit testing frameworks?
Introduction
Definition
"In computer programming, an assertion is a predicate (i.e., a true–false statement) placed in a program to indicate that the developer thinks that the predicate is always true at that place. Assertions are used to help specify programs and to reason about program correctness. For example, a precondition — an assertion placed at the beginning of a section of code — determines the set of states under which the code is expected to be executed. A postcondition — placed at the end — describes the expected state at the end of execution. "[1]
Assertions are essentially a way to implement testing in computer programming and are specified by the programmer to check for correctness in a program. Assertions are a systematic way to check that the internal state of a program is as the programmer expected, with the goal of catching bugs. In particular, they are good for catching false assumptions that were made while writing the code.
Example
Following is a very simple example of an assertion in Java.
if (i % 4 == 0) { ... } else if (i % 4 == 1) { ... } else if (i % 4 == 2) { ... } else { assert i % 4 == 3 : i; ... }
In the above example we know that if the first three conditions are false then i % 4 has to evaluate to 3 and this is asserted using assert. Note that even in this case the assertion may fail if i is negative.
Usage
- Design by Contract: Assertions may be specified at the class level (invariants) or on the method level (preconditions and postconditions). An invariant is a correctness condition imposed on a class, i.e., a condition that must not be violated by any method of a class. A precondition is associated with a particular method and imposes a correctness condition on the client or the entity using the particular method: i.e., the client must ensure that the precondition is fulfilled; otherwise the method is not executed. A postcondition is also associated with a particular method, but it imposes a correctness condition on the implementation of the method; a violation of a postcondition indicates an error in the implementation of the method.
- Runtime checking: Assertions that are a part of the implementation and can be checked at run time for correctness. This is a very common usage of assertions.
- Development Cycle: During the development cycle, assertions are used as a powerful debugging tool. The point at which the assertion failure occurs the programmer is immediately notified so that he can go ahead and fix the bug.
- Static assertions: Assertions that are checked at compile time are called static assertions.[1]
Support for assertions in various o-o programming languages
Depending on the programming language, assertions can either be a part of the design process or they could be statements which are checked at runtime. In this page we are trying to research the support for assertions present in various o-o programming languages. The research is based on two main criteria:
1. How well the support for assertions is integrated with the language
There are several ways in which assertions are supported in different languages. Listed below are few strategies for providing this support.
- Built-in support: This means that support is directly included in the programming language. The programming language contains language constructs to formulate assertions in one way or another. The syntactical correctness of assertions is checked directly by the compiler. In addition a runtime environment must be available to perform the runtime assertion checks and also should be able to selectively enable and disable assertion checking.
- Preprocessing: The general idea here is to formulate assertions separate from the program or to include the assertions as comments. A preprocessor is used to weave the assertions into the program or to transform the comments containing assertion formulas into programming language code. The main advantage of this approach is the separation of programming logic and contracts. This is important in cases, where the programming language itself does not support assertions and the programming language must not be altered. The main disadvantage of this approach is that the original program code is changed by the preprocessor, i.e., line numbers of compiler errors do not actually fit the line numbers of the program. The same problem arises with debugging or runtime exceptions.
- Metaprogramming: According to Templ metaprogramming refers to “programming at the level of program interpretation, or in other words, to extending the interpreter of a given programming language in an application-specific way. Traditionally, this concept is available only in dynamically typed and interpreted languages” [2].
2. How many different kinds of assertions the language supports
There are different kinds of assertions that can be implemented. A few of them have been listed below.
- Basic assertions: Annotations in the implementation of a method.
- Preconditions and Postconditions
- Invariants
Java
Support for assertions
Java, when developed initially, did not have any built-in support for assertions. This was probably because it's exception handling feature was very powerful. However the (beta) release 1.4 of Java 2 included a built-in assertion facility. An assertion is a statement in the JavaTM programming language that enables you to test your assumptions about your program. Java Assertion Facility is a built in kind of support since Java 1.4 release. Java supports a very simple assertion mechanism that allows to formulate correctness conditions within methods. Assertion checking can be easily enabled and disabled and traces of assertions may be eliminated completely from class files. [3]
Types of assertions
Java supports runtime assertions since it is a statically typed language. It also allows specifying the pre-condition and post-condition, internal invariant type of assertions.
A very simple switch-case example can be formulated as follows where an assertion is used for the default case where the assert false statement is executed when none of the case statements are true.
switch(color) { case Color.RED: ... break; case Color.YELLOW: ... break; case Color.BLUE: ... break; case Color.GREEN: ... default: assert false : suit; }
C++
Support for assertions
There is no native support for assertions in C++. Assertions are, however, part of the standard library header assert.h which defines the macro assert. The assert macro evaluates an expression and prints out a error message to standard error if the expression evaluates to zero. The actual message is dependent on the implementation and varies from compiler to compiler. In most cases, an assertion failure results in the termination of the program using abort.
Types of assertions
Runtime Assertions
The assert macro can be used for runtime assertions. A simple example is shown below:
#include<assert.h> int main() { int x=3; int y=4; assert((x-y)>0); //false. Will terminate the program. }
The above example checks if the difference between x and y is greater than zero. In the example above, an assertion error will be thrown resulting in the termination of the program.
Assertions during Developmental Cycles
The assert macro is defined only if NDEBUG is not defined. Therefore, a programmer can define NDEBUG using a #define NDEBUG during the release cycle to remove all assertions in the code. There is no performance penalty in this case as the preprocessor will remove all the debugging code.
Assertions in Design by Contract
Assertions in Design by Contract are supported in C++ using third party tools such as the DBC for C preprocessor, GNU Nana, C², or the Digital Mars C++ compiler.
Assertions in xUnit
In C++, there is no one standardized framework but it does have several testing frameworks with different APIs. A list of these can be found here. Most of them are ports of JUnit to C++. Since, assertions are not native to C++, each testing unit defines its own assert macros and functions. In the example listed above the assert.h standard library provides the assert() function. If the testing framework is CPPUnit, then the corresponding assert function is CPPUNIT_ASSERT(expression).
Ruby
Support for Assertions
Ruby does not have native support for assertions. Assertions are supported using the Test::Unit framework. Test::Unit::Assertions contain the standard Test::Unit assertions. Please refer to the Official Ruby Documentation for more information on using the Test::Unit framework. An assertion failure will result in the exception AssertionFailedError being thrown with the pertinent information on where the assertion failed which, if required, can be rescued by the programmer.
Types of assertions
Runtime Assertions
The Test::Unit::Assertions provides a rich set of assertion functions. A simple example is shown below:
require "test/unit" x=8 assert x>0 # will return true assert_equal(x,7,"Equality test failed!") # False. Test will fail.
Other functions include assert_match for regular expression matching.
require "test/unit" assert (/[a-z]+/, "Match12") # will fail.
A complete list of possible runtime assertions can be found at RubyDoc.
Assertions during Developmental Cycle
Since, Ruby does not have native support for assertions there is no way to turn off assertions during runtime unless the programmer explicitly does so.However, since assertions in Ruby are part of the unit testing framework, they are expected to be used only in the test fixture and not in the actual development code.
Assertions in Design by Contract
Ruby supports assertions in Design by Contract using third party libraries like Brian McCallister's DesignByContract, Ruby DBC or ruby-contract.
Assertions in xUnit
Ruby uses the Test::Unit framework for unit testing and the Test::Unit::Assertions provides the necessary assertion support. Some of the commonly used assert statements in Ruby are assert(), assert_equal(), assert_not_equal(), assert_nil(), assert_not_nil(), assert_same(), assert_not_same().
Python
Support for Assertions
Assertions in Python are built into the language and are implemented using the assert statement. The syntax for the assert statement according to the official Python documentation is as follows:
assert_stmt::="assert" expression ["," expression]
The second expression is optional. Please refer to Python Documentation for more information on the assert statement syntax. The exception AssertionError is thrown whenever an assertion fails and will usually result in the termination of the program.
Types of Assertions
Runtime Assertions
The example below checks whether a value of a variable is always positive using assertions in Python.
x=5 assert x>0 #will be true as long as x>0
In the example above, the expression x>0 will evaluate to true and therefore, no AssertionError is raised.
The assert statement can also be used for type checking since python is a dynamically typed language. This is useful in making sure the type of the arguments to an function are correct.
from types import * def foo(x,name) assert type(x) is IntType, "id is not an integer: %s" % `id` assert type(name) is StringType, "name is not String: %s" % `name`
The string expression at the end of the assert statement is printed out only if the assertion fails.
Assertions during Developmental Cycle
Assertions in Python are executed only in debug mode and can be disabled by passing the "-O" option to the python interpreter. This allows the developer to turn off assertions in the release builds to avoid unnecessary performance slowdowns.
Assertions in Design by Contract
Python does not have native support for assertions in Design by Contract(DBC). However, there are third party libraries like PyDBC or Contracts for Python which add support for DBC.
Assertions in xUnit
The standard Unit testing framework in Python is PyUnit. It is a part of the Python standard library. PyUnit is based on the JUnit framework. The pyUnit framework uses the built-in Python assert statement for assertions.
Eiffel
Support for assertions
Eiffel has native support for assertions through Design by Contract. Here, the state of the code to be executed before and after execution is explicitly defined using pre-conditions and post-conditions. These conditions are also extracted and included in the documentation of the class which ensures that the documentation stays in sync with the code.
Types of assertions
Design by Contract
Eiffel supports assertions only through Design by Contract. Eiffel uses the require statement to indicate pre-conditions and ensure statement for post-conditions. The example[1] below illustrates this using a simple dictionary insertion function.
put (x: ELEMENT; key: STRING) is -- Insert x so that it will be retrievable through key. require count <= capacity not key.empty do ... Some insertion algorithm ... ensure has (x) item (key) = x count = old count + 1 end
Assertions in xUnit
There are no unit testing frameworks for Eiffel. Design by Contract is the recommended way to test Eiffel code.
Summary
References
- [1] Wikipedia Page Assertions
- [2] Templ J.: Metaprogramming in Oberon, ETH Dissertation No. 10655, Zurich, 1994
- [3] Sun Microsystems: Java Assertion Facility
External Links
- Assertions in Python
- Assert statement in Python
- Unit Testing in Ruby
- Assertions in Ruby
- Design by Contract in Eiffel
- Design by Contract
- More information on Ruby Unit Testing
- Assertions in C++
- JUnit
- Unit testing in C++
- PyUnit.
See Also
- Programming with Assertions
- Design by Contract with Extensible C#
- Test::Unit::Assertions
- Why and How: Ruby (and Rails) Unit Testing
- WHY EIFFEL IS BETTER THAN C++
- xUnit Patterns
==