1

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?

closed as unclear what you're asking by gnat, user40980, GlenH7, mattnz, BЈовић Sep 12 '13 at 17:56

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • Sharing your research helps everyone. Tell us what you've tried and why it didn’t meet your needs. This demonstrates that you’ve taken the time to try to help yourself, it saves us from reiterating obvious answers, and most of all it helps you get a more specific and relevant answer. Also see How to Ask – gnat Sep 9 '13 at 19:53
  • I have seen both structures used. Both will work. I'm hoping one of the higher reputation Python developers knows why one might be preferred over the other. – Jace Browning Sep 9 '13 at 20:02
  • @JaceBrowning - your question would be stronger if you provided your interpretation of the two approaches and explained where you may be having difficulty in understanding the advantage of X vs. Z. Right now, it's hard to tell what you're asking and / or your question is too broad because there are too many potential answers. – GlenH7 Sep 11 '13 at 3:20
  • 1
    @GlenH7 I've added my understanding of the two approaches to the question. – Jace Browning Sep 11 '13 at 3:46
  • @MichaelT mattnz BЈовић: you all voted to close this question, but didn't provide a comment as to why. Please let me know what improvements I could make to help you answer the question. – Jace Browning Sep 15 '13 at 1:09
0

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.
  • I can see cases where this would be useful, but most guides show the tests in test packages: guide.python-distribute.org/creation.html My question is about where to put these test packages when there are multiple. – Jace Browning Sep 12 '13 at 13:18
  • @Jace Browning, I'm new to python, don't take my opinion too seriously ;p – Vorac Sep 12 '13 at 13:22

Not the answer you're looking for? Browse other questions tagged or ask your own question.