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

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