== Complete Taxonomy ==

 * Please visit the PythonTestingToolsTaxonomy for a much more complete list of test tools of all kinds.

== Software ==

 * UnitTest in the standard library (http://docs.python.org/lib/module-unittest.html)
 * PyUnit at http://pyunit.sourceforge.net
 * [[http://www.garethrees.org/2001/12/04/python-coverage/|StatementCoverage]]  This module runs your code, then produces a report on how many statements were executed, and which ones were not.  Use it to ensure your unit tests test everything.
 * DataTest at http://formencode.org/docs/DataTest/README.html
 * McCabe-like Python Cyclomatic Complexity analysis tools are available at  http://journyx.com/curt/complexity.html.  They're written in Perl, but read and analyze only Python code. Complexity is bad, this will help you simplify code - especially code you didn't write.
 * [[http://www.python.org/pypi/zope.testing|zope.testing]] provides a powerful test runner that supports test discovery and a wide range of options to control how tests are run and results reported.
 * [[http://somethingaboutorange.com/mrl/projects/nose/|nose]] is "a discovery-based [[unittest]] [[extension]]" that generally also supports PyTest functionality.

== Best Practices ==

== Discussion ==

Sprouted out by http://formencode.org/docs/DataTest/TODO.html.

What I need is a layered test system like
 * test suit
   * with fast/normal/detailed mode
   * with known failing tests excluded
 * test package to group related tests with preset parameters
 * individual test
   * with options like log details
   * with ability to flex parameters, extend options etc.
 * test utilities
   * fuzzy difference
   * different logging/reporting/visualization helpers
   * with output capture capability
-- MikeRovner <<DateTime(2004-02-27T19:25:32Z)>>