Якщо ви пишете бібліотеку чи додаток, куди йдуть файли тестових програм?

Приємно відокремлювати тестові файли від основного коду програми, але незручно їх розміщувати у підкаталозі "тести" всередині кореневого каталогу додатків, оскільки це ускладнює імпорт модулів, які ви будете тестувати.

Чи є тут найкраща практика?

Для файлу module.pyзазвичай слід викликати одиничний тест test_module.py, дотримуючись умов пітонічного іменування.

Є кілька загальноприйнятих місць, які можна поставити test_module.py:

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

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

Лише 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
• пітест

Поширена практика - помістити тестовий каталог у той самий батьківський каталог, що і ваш модуль / пакет. Отже, якщо ваш модуль називався foo.py, ваш макет каталогу виглядатиме так:

parent_dir/
  foo.py
  tests/

Звичайно, немає жодного способу зробити це. Ви також можете зробити тест-підкаталог та імпортувати модуль, використовуючи абсолютний імпорт .

Де б ви не поставили свої тести, я б рекомендував вам використовувати ніс для їх запуску. Пошук носа через ваші каталоги для проведення тестів. Таким чином, ви можете ставити тести там, де вони мають найбільш організаційний сенс.

У нас виникло те саме питання при написанні Pythoscope ( https://pypi.org/project/pythoscope/ ), який генерує одиничні тести для програм Python. Ми опитували людей на тестуванні в списку python, перш ніж обрати каталог, було багато різних думок. Врешті-решт ми вирішили помістити каталог тестів у ту саму директорію, що і вихідний код. У цьому каталозі ми генеруємо тестовий файл для кожного модуля в батьківському каталозі.

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

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

блок. Це закінчується додаванням документації до файлу як "приклад коду" для використання файлу python, який ви тестуєте.

Додам, я схильний писати дуже щільні модулі / класи. Якщо ваші модулі вимагають дуже великої кількості тестів, ви можете помістити їх в інший, але навіть тоді я все одно додаю:

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

Це дозволяє кожному, хто читає ваш вихідний код, знати, де шукати тестовий код.

Я раз у раз перевіряю тему тестового розміщення, і щоразу більшість рекомендує окрему структуру папок поруч із кодом бібліотеки, але я вважаю, що аргументи кожного разу однакові і не такі переконливі. В кінцевому підсумку я розміщую свої тестові модулі десь біля основних модулів.

Основна причина цього: рефакторинг .

Коли я пересуваю речі, я хочу, щоб тестові модулі рухалися разом із кодом; втратити тести легко, якщо вони знаходяться в окремому дереві. Будемо чесними, рано чи пізно ви закінчите зовсім іншу структуру папок, наприклад, джанго , фляшку та багато інших. Що добре, якщо вам все одно.

Головне питання, яке ви повинні задати собі, це:

Я пишу:

• а) бібліотеку для багаторазового використання або
• б) побудова проекту, ніж зв'язує разом деякі напіввідділені модулі?

Якщо:

Окрема папка та додаткові зусилля для підтримання її структури можуть бути більш підходящими. Ніхто не скаржиться на те, що ваші тести будуть розгорнуті у виробництво .

Але також так само просто виключити тести з розповсюдження, коли вони змішуються з основними папками; помістіть це в setup.py :

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

Якщо b:

Ви можете побажати - як і кожен з нас - писати бібліотеки для багаторазового використання, але більшу частину часу їхнє життя пов'язане з життям проекту. Можливість легко підтримувати свій проект повинна бути пріоритетом.

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

Отже, вибір все одно за вами, але я б заперечував, що за допомогою змішаних тестів ви досягаєте всіх тих самих речей, що і в окремій папці, але з меншими зусиллями на те, щоб утримати речі в порядку.

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

from .. import foo

імпортувати MyApp.fooмодуль.

Я не вірю, що існує «найкраща практика».

Я ставлю свої тести в інший каталог поза кодом програми. Потім я додаю основний каталог додатків до sys.path (що дозволяє імпортувати модулі з будь-якого місця) у мій сценарій тестування бігуна (що також робить деякі інші речі) перед запуском усіх тестів. Таким чином, я ніколи не повинен видаляти каталог тестів з основного коду, коли випускаю його, економлячи час і зусилля, якщо ця невелика кількість.

З мого досвіду розробки фреймворків тестування в 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, ви можете просто упакувати основні модулі бібліотеки (лише). Це сприяє ремонту, особливо в спритних умовах.

Я рекомендую вам переглянути деякі основні проекти 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

Як я це роблю ...

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

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

Setup.py вказує на src / як на місце, що містить модулі моїх проектів, тоді я запускаю:

setup.py develop

Що додає мій проект у пакунки для сайтів, вказуючи на мою робочу копію. Для запуску тестів я використовую:

setup.py tests

Використовуючи тест-бігун, який я налаштував.

Я віддаю перевагу каталогу тестів на рівні рівнів. Це означає, що імпорт стає дещо складнішим. Для цього у мене є два рішення:

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

Якщо ви віддаєте перевагу запускати тести з носами, можливо, вам доведеться зробити дещо інше.

Ми використовуємо

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

У кожному з тестового файлу ми вставляємо ../src/в sys.path. Це не найприємніше рішення, але працює. Я думаю, що було б чудово, якби хтось придумав w / щось на кшталт maven in java, що дає стандартні умови, які просто працюють, незалежно від того, над яким проектом ви працюєте.

Якщо тести прості, просто покладіть їх у docstring - більшість тестових рамок для Python зможуть використовувати це:

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

Для інших більш задіяних тестів я б розміщував їх ../tests/test_module.pyабо в tests/test_module.py.

У C # я загалом розділив тести на окрему збірку.

У Python - поки що - я схильний або писати doctests, де тест знаходиться в docstring функції, або розміщувати їх у if __name__ == "__main__"блоці внизу модуля.

Під час написання пакету під назвою "foo" я перенесу одиничні тести в окремий пакет "foo_test". Потім модулі та субпакети матимуть те саме ім'я, що і модуль пакету SUT. Напр. Тести для модуля foo.xy знаходяться у foo_test.xy Файли __init__.py кожного тестового пакету містять пакет AllTests, який включає всі тестові набори пакету. setuptools пропонує зручний спосіб вказати основний пакет тестування, так що після "python setup.py development" ви можете просто використовувати "python setup.py test" або "python setup.py test -s foo_test.x.SomeTestSuite" до просто конкретний набір.

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

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

Як зазначали інші , це також полегшує переробку та витяг коду для використання в іншому місці, якщо це буде необхідно.

Мені дуже не подобається ідея розміщувати тести у зовсім іншому дереві каталогів; Чому розробникам важче, ніж потрібно, для відкриття тестів, коли вони відкривають файл із CUT? Це не так, як переважна більшість розробників настільки захоплюються написанням або налаштуванням тестів, що вони ігнорують будь-який бар'єр для цього, замість того, щоб використовувати бар'єр як привід. (На моєму досвіді, навпаки; навіть коли ви це зробите максимально просто, я знаю багатьох розробників, які не можуть заважати писати тести.)

Нещодавно я почав програмувати в Python, тому ще не мав шансів дізнатися найкращу практику. Але я написав модуль, який йде і знаходить усі тести і виконує їх.

Отже, у мене є:

додаток /
 appfile.py
тест /
 appfileTest.py

Мені доведеться побачити, як це відбувається в міру просування до великих проектів.