In article <[EMAIL PROTECTED]>, Torsten Bronger <[EMAIL PROTECTED]> 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.
-- http://mail.python.org/mailman/listinfo/python-list
