Должны ли Python unittests быть в отдельном модуле?

Есть ли консенсус относительно наилучшего места для путтов Python?

Если unittests будет включен в тот же модуль, что и тестируемые функции (выполняется, когда модуль запускается самостоятельно (if __name__ == '__main__' и т.д.)), или лучше включить unittests в разные модули?

Возможно, комбинация обоих подходов лучше всего, включая тесты уровня модуля в каждом модуле и добавление тестов более высокого уровня, которые тестируют функциональность, включенную в несколько модулей как отдельные модули (возможно, в подкаталог /test ).

Я предполагаю, что обнаружение теста более прямолинейно, если тесты включены в отдельные модули, но есть дополнительная нагрузка для разработчика, если он/она должен помнить о необходимости обновления дополнительного тестового модуля, если модифицированный модуль изменен.

Мне было бы интересно узнать мысли людей о наилучшем способе организации unittests.

Ответ 1

Если вам нужно, если вы используете библиотеку, определяющую, где должны жить unittests,
в самих модулях для небольших проектов или
в подкаталоге tests/ в вашем пакете для более крупных проектов.

Это вопрос того, что лучше всего подходит для проекта, который вы создаете.

Иногда библиотеки, которые вы используете, определяют, где должны проходить тесты, как в случае с Django (где вы помещаете свои тесты в подкаталог models.py, tests.py или tests/ в приложениях).

Если нет существующих ограничений, это вопрос личных предпочтений. Для небольшого набора модулей может быть удобнее разместить unittests в файлах, которые вы создаете.

Для чего-либо большего, чем несколько модулей, я создаю тесты отдельно в каталоге tests/ в пакете. При тестировании кода, смешанного с реализацией, добавляется лишний шум для всех, кто читает код.

Ответ 2

ДА, используйте отдельный модуль.

На самом деле нет смысла использовать трюк __main__. Предположим, что у вас в вашем модуле несколько файлов, и он больше не работает, потому что вы не хотите запускать каждый исходный файл отдельно при тестировании вашего модуля.

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

Нет, действительно. Поместите свои тесты в tests/, ваш документ в doc и создайте Makefile для make test. Любые другие подходы являются лишь промежуточными решениями, действительными только для отдельных крошечных модулей.

Ответ 3

Лично я создаю тестовую папку в исходном каталоге и пытаюсь более или менее зеркально отразить мою основную иерархию исходного кода с эквивалентами unit test (с одним модулем 1 модуль = 1 unit test как правило).

Обратите внимание, что я использую nose, и его философия немного отличается от того, что нужно для unittest.

Ответ 4

Я обычно держу тестовый код в отдельном модуле и отправляю модуль/пакет и тесты в одном дистрибутиве. Если пользователь устанавливает с помощью setup.py, они могут запускать тесты из тестового каталога, чтобы убедиться, что все работает в их среде, но только код модуля заканчивается под Lib/site-packages.

Ответ 5

При использовании проверки if __name__ == '__main__' могут быть другие причины, кроме тестирования. Сохранение тестов в других модулях оставляет эту возможность открытой для вас. Кроме того, если вы реорганизовываете реализацию модуля, а ваши тесты находятся в другом модуле, который не редактировался, вы ЗНАЕТЕ, что тесты не были изменены, когда вы запускаете их против реорганизованного кода.

Ответ 6

Я обычно использую их в отдельной папке, которая чаще всего называется test/. Лично я не использую проверку if __name__ == '__main__', потому что я использую nosetests и сам обрабатывает обнаружение теста.

Ответ 7

if __name__ == '__main__' и т.д. отлично подходит для небольших тестов.