Unit Test
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 - Test-DrivenDevelopment.
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 Web Unit toolkit ; Sancho framework
- Dive Into Python chapter
- discussion of approaches
- Doc Test [puts](http://www.python.org/pycon/dc2004/papers/4/PyCon2004Doc TestUnit/) 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
- Test O O B 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 FrameWork 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.
- Coverage.py measures code coverage, typically during test execution. It uses the code analysis tools and tracing hooks provided in the Python standard library to determine which lines are executable, and which have been executed.
- and WebApp testing frameworks like WikiWikiWeb:HttpUnit, etc.
- some Chris Dent ideas from SocialText, using Python and YAML.
- or Selenium?
- 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.
Edited: | Tweet this! | Search Twitter for discussion