Which is the preferred test package structure for packages containing subpackages:
Tests in Subpackages?
a/
__init__.py
b.py
c/
__init__.py
cc.py
test/
__init__.py
test_cc.py
d.py
test/
__init__.py
test_b.py
test_d.py
This structure suggests that each subpackage is a cohesive unit that can be tested (and possibly later released) by itself.
Subpackages in Tests?
a/
__init__.py
b.py
c/
__init__.py
cc.py
d.py
test/
__init__.py
test_b.py
test_c/
__init__.py
test_cc.py
test_d.py
This structure does a better job of keeping the tests in one place, but makes it a little harder to run the tests for a particular subpackage.
Something else?
5
I am probably misunderstanding the question. Nevertheless, here is a go. Please, guide me to the precise question of interest by the means of comments.
Why not place the test within the modules themselves?
def main():
pass
if __name__ == "__main__":
main()
- It is idiomatic.
- It provides two different uses for every module – to be included and used by other code, or to be called directly, in which case test are run.
- Is quite handy during development. When working on a module, one usually wants to see first how the local changes are affecting the module, not that 12731 out of 13000 tests passed.
- Tests can generally be customized so that there is a test that invokes local functionality, mocking all children, and a different test to import the sub-modules usually used and do some tests that are closer to the real world use of the module. This is very handy when a sub-module is broken, but you need to work on the higher-in-the-hierarchy module.
2