Должны ли тесты Python находиться в отдельном модуле?

Question

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

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

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

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

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

Answer 1

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

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

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

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

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

Answer 2

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

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

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

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

Answer 3

Лично я создаю папку «tests /» в своем исходном каталоге и пытаюсь более или менее отразить мою основную иерархию исходного кода с помощью эквивалентов модульных тестов (имея, как правило, 1 модуль = 1 модуль модульного тестирования).

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

Answer 4

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

Answer 5

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

Answer 6

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

Answer 7

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