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?
Unit testing means testing individual modules of an application in isolation (without any interaction with dependencies) to confirm that the code is doing things right. Integration testing means checking if different modules are working fine when combined together as a group.
unittest has been built into the Python standard library since version 2.1. You'll probably see it in commercial Python applications and open-source projects. unittest contains both a testing framework and a test runner. unittest has some important requirements for writing and executing tests.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With