unittest: which directory structure?

Roy Smith roy at panix.com
Sat Apr 12 12:52:09 EDT 2008


In article <87zlrzw1f5.fsf at physik.rwth-aachen.de>,
 Torsten Bronger <bronger at physik.rwth-aachen.de> wrote:

> Hallöchen!
> 
> I try to port my doctests to unittest.  I've found good turorials
> about *writing* unit tests but not about organising the files.
> 
> What's the best way to arrange the test source files?  I made a
> directory called "tests" on the same level as my package, with
> (roughly) one test module per package module and wanted to call each
> of them from my Makefile or from some sort of root test module.

When I first started using unittest, I did the same thing you did -- I put 
the test files in some other directory.  This forced me into having to play 
the same sorts of tricks you're playing with sys.path so you could import 
your modules into the test framework.  It also turned out to be more work 
for me during normal development, having to go into one directory to edit a 
test, then into another to edit the class being tested.

Ultimately, I've come to the conclusion that just putting the production 
code and tests in the same directory is easier.

Your next decision is how to name the files.  You could put the tests for 
foo.py in test_foo.py, or foo_test.py (or a million other minor variations 
on spelling and punctuation).  Using a "test_" *prefix* means all the tests 
sort to the end of the directory listing, so the production code and the 
test code stay separated from each other.  Using a _test *suffix*, means 
the tests for a given module sort next to the module itself.

This is the sort of decision which, while ultimately unimportant, has the 
ability to consume the entire development group in days (if not weeks) of 
religious debate.  Just pick a style, go with it, and make sure everybody 
on the team sticks with the same style.



More information about the Python-list mailing list