[Python-Dev] Unittest PEP do's and don'ts (BDFL pronouncement)

C. Titus Brown ctb at msu.edu
Thu Jul 17 00:11:54 CEST 2008


On Wed, Jul 16, 2008 at 10:37:46PM +0100, Michael Foord wrote:
-> >test_sort2.py :
-> >
-> > def test_me():
-> >    seq = [ 5, 4, 1, 3 2 ]
-> >    seq.sort()
-> >    assert seq == [1, 2, 3, 4, 5]
-> >
-> >The *only value* that unittest adds here is in the 'assertEqual'
-> >statement, which (I think) returns a richer error message than 'assert'.
-> 
-> But if you exclude the import and class definition (two lines), then the 
-> test methods themselves are identical - except with unittest you have 
-> the advantage of the 'assertEquals' error collecting and reporting.
-> 
-> The boilerplate at the end is useful for running the test file in 
-> isolation, but you don't include anything comparable in the second example.

You omit import and class definition (two lines), as well as 'self' in
every function definition.  And don't forget the multiple levels of
indentation -- that's a fair amount of gratuitous typing & boilerplate,
IMO.

With nose and py.test you always have a test runner and you can run the
tests with

	nosetests test_sort2.py

which to my mind is better than having it be the default __main__
function, anyway.

-> >If I could run the second program by doing
-> >
-> >	unittest.discover_tests('test_sort2.py')
-> >
-> >I would be a very happy man... right now it requires installing nose or
-> >py.test.
-> >
-> What about if you could run all tests in a project (of the first kind) with:
-> 
-> tests = unittest.discover_tests('path/', filter='*test.py')
-> unittest.run_tests(tests)
-> 
-> (or even just the first line).

I would very much like that, although I think some sensible defaults
would let you omit the filter and path in obvious cases (test_*.py and
cwd, basically).

I think the exact test discovery behavior is solved in similar ways by the
py.test and nose folks, and the GCD of these solutions would provide a
good baseline for unittest.  Having *one* Python-general way to name
your test files and test functions/classes that is also compatible
across nose, py.test, and unittest would be a real gain for Python, IMO.

You could even set the default unittest __main__ to run the
discover_tests function, e.g.

	python -m unittest [<directory> [<filter>]]

or some such...

cheers,
--titus
-- 
C. Titus Brown, ctb at msu.edu


More information about the Python-Dev mailing list