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?

Asked By: Jace Browning

||

Source

Answer 1

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.

Answered By: running.t

Answer 2

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

Answered By: Nathan Wailes

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

Question:

Answers: