In article <87zlrzw1f5.fsf @physik.rwth-aachen.de>,
Torsten Bronger <bronger@physik .rwth-aachen.dewrote:
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.
Torsten Bronger <bronger@physik .rwth-aachen.dewrote:
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.
>
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.
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.