Is there a convention to distinguish Python integration tests from unit tests?

Question

The most common way of structuring a Python package with unit tests is as follows:

package/
    __init__.py
    module_1.py
    module_2.py
    module_n.py
    test/
        __init__.py
        test_module_1.py
        test_module_2.py
        test_module_n.py

I would like to distinguish between unit tests (of methods and functions) and integration tests (using the whole package and possibly involving other resources). Perhaps these tests should be in different packages, have different filenames, and/or include certain docstring comments.

Is there a standard convention for doing this?

score 26 · Accepted Answer · edited Apr 09 '13 at 08:50

26

In our project we have unit tests inside each package, same as your case, and integration tests ,system tests, as a separate package on top level, i.e:

package_1/
  __init__.py
  module_1.py
  module_n.py
  test/
    __init__.py
    test_module_1.py
    test_module_n.py
package_n/
  __init__.py
  module_1.py
  module_n.py
  test/
    __init__.py
    test_module_1.py
    test_module_n.py
systemtest/
  __init__.py
  systemtest_1.py
  systemtest_n.py

I would use this convention even if you've got only one package in project. However I am not sure if this is a standard convention, or not.

edited Apr 09 '13 at 08:50

Atilla Ozgur

14,339
3
49
69

answered Apr 08 '13 at 14:22

running.t

5,329
3
32
50

I would really like to keep integration tests for a package within that package. – Jace Browning Apr 08 '13 at 15:30
2

In that case I would create 2 separate subpackages iside your package (one called test and one called systemtest) but this is definatelly not a convention but my guess. – running.t Apr 09 '13 at 12:37
1

@JaceBrowning: Isn't it part of the "integration test" thing, that more than one package may be involved? In this case the position of this test sould be above any unit test. – Christoph Jüngling Apr 10 '13 at 12:41
1

@ChristophJüngling, by "other resources" I am referring to things like file and network IO -- things which should normally be mocked in unit tests but included in integration tests. – Jace Browning Apr 10 '13 at 15:53

score 4 · Answer 2 · answered Feb 18 '19 at 02:10

I just researched this for myself and found this suggestion helpful:

project/
│
├── my_app/
│   └── __init__.py
│
└── tests/
    |
    └── unit/
    |   ├── __init__.py
    |   └── test_sum.py
    |
    └── integration/
        |
        ├── example_data/
        |   ├── test_basic.json
        |   └── test_complex.json
        |
        ├── __init__.py
        └── test_integration.py

Is there a convention to distinguish Python integration tests from unit tests?

2 Answers2