Я не верю, что существует устоявшаяся «лучшая практика».

Я помещаю свои тесты в другой каталог вне кода приложения. Затем я добавляю основной каталог приложения в sys.path (позволяющий импортировать модули из любого места) в свой сценарий запуска тестов (который также выполняет некоторые другие действия) перед запуском всех тестов. Таким образом, мне никогда не придется удалять каталог тестов из основного кода при его выпуске, что экономит мое время и усилия, пусть даже и очень незначительные.

Распространенной практикой является размещение каталога тестов в том же родительском каталоге, что и ваш модуль / пакет. Итак, если бы ваш модуль назывался foo.py, макет вашего каталога выглядел бы так:

parent_dir/
  foo.py
  tests/

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

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

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

Так что я:

app/
 appfile.py
test/
 appfileTest.py

Мне нужно будет посмотреть, как это будет происходить, когда я перейду к более крупным проектам.

Я использую каталог tests/, а затем импортирую основные модули приложения, используя относительный импорт. Итак, в MyApp / tests / foo.py может быть:

from .. import foo

для импорта модуля MyApp.foo.

В C# я обычно выделяю тесты в отдельную сборку.

В Python - до сих пор - я имел тенденцию либо писать тесты, где тест находится в строке документации функции, либо помещать их в блок if __name__ == "__main__" в нижней части модуля.

Для файла module.py модульный тест обычно должен называться test_module.py в соответствии с соглашениями об именах Pythonic.

Есть несколько общепринятых мест для размещения test_module.py:

1. В том же каталоге, что и module.py.
2. В ../tests/test_module.py (на том же уровне, что и каталог кода).
3. В tests/test_module.py (один уровень под каталогом кода).

Я предпочитаю №1 из-за простоты поиска тестов и их импорта. Какую бы систему сборки вы ни использовали, ее можно легко настроить для запуска файлов, начиная с test_. Собственно, файл шаблон unittest по умолчанию, используемый для обнаружения тестов - test*.py.

При написании пакета под названием «foo» я помещу модульные тесты в отдельный пакет «foo_test». Модули и подпакеты будут иметь то же имя, что и модуль пакета SUT. Например. тесты для модуля foo.x.y находятся в foo_test.x.y. Файлы __init__.py каждого пакета тестирования затем содержат набор AllTests, который включает все наборы тестов пакета. setuptools предоставляет удобный способ указать основной пакет тестирования, так что после «python setup.py develop» вы можете просто использовать «python setup.py test» или «python setup.py test -s foo_test.x.SomeTestSuite» для просто конкретный сюит.

Если тесты простые, просто поместите их в строку документации - большинство тестовых фреймворков для Python смогут это использовать:

>>> import module
>>> module.method('test')
'testresult'

Для других более сложных тестов я бы поместил их либо в ../tests/test_module.py, либо в tests/test_module.py.

Я также стараюсь помещать свои модульные тесты в сам файл, как отмечает Джереми Кантрелл выше, хотя я стараюсь не помещать тестовую функцию в основное тело, а скорее помещаю все в

if __name__ == '__main__':
   do tests...

блокировать. В итоге в файл добавляется документация в виде «примера кода» для использования тестируемого файла python.

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

if __name__ == '__main__':
   import tests.thisModule
   tests.thisModule.runtests

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

Мы используем

app/src/code.py
app/testing/code_test.py 
app/docs/..

В каждый тестовый файл мы вставляем ../src/ в sys.path. Это не самое лучшее решение, но оно работает. Я думаю, было бы здорово, если бы кто-то придумал что-то вроде maven в java, которое дает вам стандартные соглашения, которые просто работают, независимо от того, над каким проектом вы работаете.

Я предпочитаю каталог тестов верхнего уровня. Это означает, что импорт становится немного сложнее. Для этого у меня есть два решения:

1. Используйте setuptools. Затем вы можете передать test_suite='tests.runalltests.suite' в setup() и просто запустить тесты: python setup.py test
2. Установите PYTHONPATH при запуске тестов: PYTHONPATH=. python tests/runalltests.py

Вот как это поддерживается кодом в M2Crypto:

• http://svn.osafoundation.org/m2crypto/trunk/setup.py
• http://svn.osafoundation.org/m2crypto/trunk/tests/alltests.py

Если вы предпочитаете проводить тесты с помощью носовых тестов, возможно, вам нужно сделать что-то другое.

Тот же вопрос возник у нас при написании Pythoscope (https://pypi.org/project/pythoscope/), который генерирует модульные тесты для программ Python. Перед тем, как выбрать каталог, мы опросили людей о тестировании в списке Python, было много разных мнений. В конце концов, мы решили поместить каталог «tests» в тот же каталог, что и исходный код. В этом каталоге мы генерируем тестовый файл для каждого модуля в родительском каталоге.

Как я это делаю ...

Структура папки:

project/
    src/
        code.py
    tests/
    setup.py

Setup.py указывает на src / как расположение, содержащее модули моих проектов, затем я запускаю:

setup.py develop

Что добавляет мой проект в пакеты сайтов, указывая на мою рабочую копию. Для запуска своих тестов я использую:

setup.py tests

Используя тот тестовый раннер, который я настроил.

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

                              <Main Package>
                               /          \
                              /            \
                            lib           tests
                            /                \
             [module1.py, module2.py,  [ut_module1.py, ut_module2.py,
              module3.py  module4.py,   ut_module3.py, ut_module.py]
              __init__.py]

Таким образом, когда вы упаковываете эти библиотеки с помощью rpm, вы можете просто упаковать модули основной библиотеки (только). Это способствует удобству обслуживания, особенно в гибкой среде.

Всего 1 тестовый файл

Если имеется только 1 тестовый файл, рекомендуется поместить его в каталог верхнего уровня:

module/
    lib/
        __init__.py
        module.py
    test.py

Запустить тест в CLI

python test.py

Множество тестовых файлов

Если у вас много тестовых файлов, поместите его в папку tests:

module/
    lib/
        __init__.py
        module.py
    tests/
        test_module.py
        test_module_function.py

# test_module.py

import unittest
from lib import module

class TestModule(unittest.TestCase):
    def test_module(self):
        pass

if __name__ == '__main__':
    unittest.main()

Запустить тест в CLI

# In top-level /module/ folder
python -m tests.test_module
python -m tests.test_module_function

Используйте unittest discovery

unittest discovery найдет все тесты в папке пакета.

Создайте __init__.py в папке tests/

module/
    lib/
        __init__.py
        module.py
    tests/
        __init__.py
        test_module.py
        test_module_function.py

Запустить тест в CLI

# In top-level /module/ folder

# -s, --start-directory (default current directory)
# -p, --pattern (default test*.py)

python -m unittest discover

Ссылка

• pytest Передовой опыт для тестового макета
• unittest

Фреймворк модульного тестирования

• нос
• нос2
• pytest

Я рекомендую вам проверить некоторые основные проекты Python на GitHub и почерпнуть некоторые идеи.

Когда ваш код становится больше и вы добавляете больше библиотек, лучше создать тестовую папку в том же каталоге, что и у вас setup.py, и отразить структуру каталогов вашего проекта для каждого типа теста (unittest, интеграция, ...)

Например, если у вас есть такая структура каталогов:

myPackage/
    myapp/
       moduleA/
          __init__.py
          module_A.py
       moduleB/
          __init__.py
          module_B.py
setup.py

После добавления тестовой папки у вас будет такая структура каталогов, как:

myPackage/
    myapp/
       moduleA/
          __init__.py
          module_A.py
       moduleB/
          __init__.py
          module_B.py
test/
   unit/
      myapp/
         moduleA/
            module_A_test.py
         moduleB/
            module_B_test.py
   integration/
          myapp/
             moduleA/
                module_A_test.py
             moduleB/
                module_B_test.py
setup.py

Многие правильно написанные пакеты Python используют ту же структуру. Очень хороший пример - пакет Boto. Проверить https://github.com/boto/boto

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

Основная причина для этого: рефакторинг.

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

Главный вопрос, который вы должны себе задать:

Я пишу:

• а) многоразовая библиотека или
• б) создание проекта, чем объединение нескольких полураздельных модулей?

Если:

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

Но также легко исключить тесты из распространения, если они смешаны с основными папками; поместите это в setup.py:

find_packages("src", exclude=["*.tests", "*.tests.*", "tests.*", "tests"]) 

Если b:

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

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

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

Я помещаю свои тесты в тот же каталог, что и тестируемый код (CUT); для foo.py тесты будут проводиться в foo_ut.py или аналогичном. (Я настраиваю процесс обнаружения тестов, чтобы найти их.)

Это помещает тесты рядом с кодом в список каталогов, делая очевидным, что тесты есть, и делает открытие тестов настолько простым, насколько это возможно, когда они находятся в отдельном файле. (Для редакторов командной строки, vim foo* и при использовании графического браузера файловой системы просто щелкните файл CUT, а затем непосредственно соседний тестовый файл.)

Как и другие указали, это также упрощает рефакторинг и извлечение кода для использования в другом месте, если это когда-либо понадобится.

Мне очень не нравится идея размещать тесты в совершенно другом дереве каталогов; зачем делать разработчикам сложнее, чем необходимо, открывать тесты, когда они открывают файл с помощью CUT? Не похоже, что подавляющее большинство разработчиков настолько увлечены написанием или настройкой тестов, что они игнорируют любые препятствия для этого, вместо того, чтобы использовать барьер в качестве оправдания. (По моему опыту, как раз наоборот; даже если вы делаете это как можно проще, я знаю многих разработчиков, которым не нужно писать тесты.)