[Unit Tests] are programs written to run in batches and test classes. Each typically sends a class a fixed message and verifies it returns the predicted answer. In Extreme Programming you write the Unit Test before you write the code - WikiWikiWeb:TestDrivenDevelopment.

WikiWikiWeb:UnitTest

In Extreme Programming sometimes known as [Programmer Test].

Different from Onsite Customer's Acceptance Test.

Martin Fowler distinguishes some different kind of fake/stub objects you might use in a test framework

The standard setup is [JUnit], [PyUnit]/WikiWikiWeb:PythonUnit, etc.

More PyThon: built-in 'unittest'; [PyUnit] and [WebUnit] toolkit ; Sancho framework

• [Dive Into Python] chapter

• discussion of approaches

• [DocTest] puts tests into doc strings

• [David Mertz] Apr2004 article on unittest and doctest

• doctest soapbox - The first word in "doctest'' is "doc,'' and that's why the author wrote doctest: to keep documentation up to date. It so happens that doctest makes a pleasant unit testing environment, but that's not its primary purpose... For exhaustive testing, or testing boring cases that add no value to the docs, define a __test__ dict instead. That's what it's for.

• Bruce Eckel is playing with something similar to doctest in JaVa. Some people are not thrilled with this approach.

• [Phil Pfeiffer] announces his [ADEPT] framework

• [TestOOB] http://testoob.sourceforge.net/

• Agile Testing blog includes lots of PyThon bits

  • series of posts comparing unittest to doctest to py.test - last posting tries to sum up - An interesting question is how to best combine the strengths of the 3 tools I discussed (unittest, doctest and py.test). It seems that many people are already using unittest in conjunction with doctest, with the former being used in situations that demand fixture setup and teardown, and the latter in situations where small functions need to be tested without the overhead of creating test case classes. Regardless of the style of testing, doctest seems to be a great way of keeping documentation in sync with the code. At the same time, py.test can either coexist with or replace unittest in those cases where test fixture management and test organization are important.

    • and using epydoc and doctest together for integrated testing and documentation

  • Phillip J Eby defends unittest as a Frame Work and gives a summary of how to use/extend it. The doctest module in Python 2.4 provides [APIs] to create unittest-compatible test cases from doctests, which means that I can use doctest in conjunction with my existing 800+ unittest-based test cases. I can't do that with py.test or twisted.trial or any other from-scratch framework that discards the superlative design of the unittest module. unittest may be a mediocre tool, but it's an excellent framework that would allow us to all develop tools that work together.

  • and WebApp testing frameworks like WikiWikiWeb:HttpUnit, etc.

User Options Recent Changes Help Page