Где я должен поставить тесты при упаковке модулей Python?

Question

У меня есть модуль, который находится в пространстве имен.Должны ли тесты и данные, на которые опираются тесты, идти в пространство имен или на верхний уровень, где находятся сайты setup.py?

./company/__init__.py
./company/namespace/__init__.py
./company/namespace/useful.py
./company/namespace/test_useful.py
./company/namespace/test_data/useful_data.xml
./setup.py

или

./company/__init__.py
./company/namespace/__init__.py
./company/namespace/useful.py
./test_useful.py
./test_data/useful_data.xml
./setup.py

Означает ли вопрос, должны ли тестыбыть установлен или нет?

Answer 1

Образец проекта сохраняет тесты вне модуля.

Структура каталогов выглядит следующим образом:

├── data
│   └── data_file
├── MANIFEST.in
├── README.rst
├── sample
│   ├── __init__.py
│   └── package_data.dat
├── setup.cfg
├── setup.py
└── tests
    ├── __init__.py
    └── test_simple.py

Связанный: Руководство по упаковке: https://packaging.python.org/en/latest/

Подсказка: не следуйте "Руководству по упаковке автостопом". Он не обновлялся с 2010 года!

(не путайте обе страницы. "Руководство автостопом по Python" - очень солидная книга)

Answer 2

Вы должны поместить свой тестовый модуль в модуль, который он тестирует в соответствии с Руководством по упаковке автостопом .

Вот их пример:

TowelStuff/
    bin/
    CHANGES.txt
    docs/
    LICENSE.txt
    MANIFEST.in
    README.txt
    setup.py
    towelstuff/
        __init__.py
        location.py
        utils.py
        test/
            __init__.py
            test_location.py
            test_utils.py

Таким образом, ваш модуль будет распространяться со своими тестами, и пользователи могут использовать их для проверки того, что он работает с их настройками.

См. http://the -hitchhikers-guide-to-packaging.readthedocs.org / en / latest / creation.html .

Answer 3

Я лично создаю отдельный пакет tests как подпакет основного пакета по нескольким причинам:

• Если tests параллельно с корневым пакетом, естьНе случайно вы или пользователь можете неправильно настроить setup.py и случайно выставить глобальный пакет с именем tests, который вызовет большую путаницу и головную боль, пока вы не поймете, что произошло.Помещение его в основной модуль решает эту проблему, так как теперь оно находится в (мы надеемся) глобально уникальном пространстве имен.

• Мне не нравится помещать тестовый модуль в пользовательский пакет, потому что бегунам тестов приходится искатьчерез производственный код.Это, вероятно, не проблема для большинства.Но, если вы оказались инженером по тестированию оборудования, вы, вероятно, часто используете слово «тест» в своем производственном коде и не хотите, чтобы тестировщик unit принимал это.Гораздо проще, если все тесты находятся в одном месте отдельно от производственного кода.

• Я могу в дальнейшем разделить свою папку тестов на типы тестов, такие как unit, functional и integration.Мои функциональные тесты имеют тенденцию зависеть от странного проприетарного оборудования, данных или работают медленно.Так что мне легко непрерывно запускать только папку быстрого модульного тестирования, пока я разрабатываю.

• Иногда бывает удобно, чтобы тесты были в той же иерархии пакетов, что и они.testing.

В целом, я думаю, важно подумать о том, что лучше для вашей конкретной проблемной области, после того, как вы учли все советы.«Лучшие практики» являются отличной отправной точкой, а не конечной точкой для разработки процесса.