It's basically between test_foo.py and foo_test.py, though one might
argue that if tests are in a tests/ directory, you shouldn't need to
prefix/suffix each file with test because the path already has it. However,
it seems like many testing frameworks — such as nose — really want that.
With regards to auto-completion, smarter searches such as Ctrl+P for vim
might make points about it less noteworthy, however, one can often end up on
odd servers where only bash (and thus only prefix completion) is available.
- Allows you to quickly replace a
.pywith_test.py. foo.<tab>and (foo_<tab>tofoo_test<tab>) to auto-complete.
- Groups tests together in a listing.
- Anything from
foo.<tab>and (t<tab>foo.<tab>totest_foo.<tab>) to auto-complete.
I consider the foo_test.py to have better auto complete: it's much less
likely to have many things colliding on a module's full name, whereas
test_foo's completion pattern collides with anything starting with t.
Options:
- Right next to the source. Where ever
foo.pyis, the test isfoo_test.py.+Easy to locate your test../<name of file minus .py>_test.py-Tests are scattered about.
- In
my_top_level_package/tests. - In
my_top_level_package/../tests. (In the repo root typically; same directory assetup.pyfor example.)
If your answer is "no", then you've essentially chosen
my_top_level_package/../tests. It may be useful to be able to run the tests
in order to validate an installation, however.
One downside is that installing tests alongside the code also requires test-only dependencies to be installed. (Or otherwise, you have a test module you perhaps can't import.)