Interrupted 1 error during collection

Package      Version
------------ -------
atomicwrites 1.4.0
attrs        21.4.0
colorama     0.4.4
iniconfig    1.1.1
packaging    21.3
pip          21.2.3
pluggy       1.0.0
py           1.11.0
pyparsing    3.0.8
pytest       7.1.1
setuptools   57.4.0
tomli        2.0.1

Call python test.py (https://docs.pytest.org/en/7.1.x/how-to/usage.html#calling-pytest-from-python-code)

def test_percent():
    pass

import pytest,sys
pytest.main([sys.argv[0], '-vvv',])
exit(0)

Output:

========================================================================== test session starts ===========================================================================
platform win32 -- Python 3.9.7, pytest-7.1.1, pluggy-1.0.0 -- C:Pythonpython.exe
cachedir: .pytest_cache
rootdir: C:Python
collected 0 items / 1 error

================================================================================= ERRORS =================================================================================
_____________________________________________________________________ ERROR collecting test session ______________________________________________________________________
d:test.py:6: in <module>
    exit(0)
lib_sitebuiltins.py:26: in __call__
    raise SystemExit(code)
E   SystemExit: 0
---------------------------------------------------------------------------- Captured stdout -----------------------------------------------------------------------------
============================= test session starts =============================
platform win32 -- Python 3.9.7, pytest-7.1.1, pluggy-1.0.0 -- C:Pythonpython.exe
cachedir: .pytest_cache
rootdir: C:Python
collecting ... collected 1 item

::test_percent <- d:test.py PASSED                       [100%]

============================== 1 passed in 0.01s ==============================
======================================================================== short test summary info =========================================================================
ERROR  - SystemExit: 0
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Interrupted: 1 error during collection !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
============================================================================ 1 error in 0.29s ============================================================================

Code on Lib/_sitebuiltins.py:

 1: """
 2: The objects used by the site module to add custom builtins.
 3: """
 4: 
 5: # Those objects are almost immortal and they keep a reference to their module
 6: # globals.  Defining them in the site module would keep too many references
 7: # alive.
 8: # Note this means this module should also avoid keep things alive in its
 9: # globals.
10: 
11: import sys
12: 
13: class Quitter(object):
14:     def __init__(self, name, eof):
15:         self.name = name
16:         self.eof = eof
17:     def __repr__(self):
18:         return 'Use %s() or %s to exit' % (self.name, self.eof)
19:     def __call__(self, code=None):
20:         # Shells like IDLE catch the SystemExit, but listen when their
21:         # stdin wrapper is closed.
22:         try:
23:             sys.stdin.close()
24:         except:
25:             pass
26:         raise SystemExit(code)

Related: #8986 warn when the cmdline_main hook raises systemexit

ImportError while importing test module

========================================================= test session starts ==========================================================
platform linux — Python 3.9.5, pytest-7.0.1, pluggy-1.0.0
rootdir: /home/andrei/python/pytest/app/tests
collected 0 items / 1 error

================================================================ ERRORS ================================================================
____________________________________________________ ERROR collecting test_psum.py _____________________________________________________

ImportError while importing test module ‘/home/andrei/python/pytest/app/tests/test_psum.py’.

Hint: make sure your test modules/packages have valid Python names.

Traceback:
../../../../.pyenv/versions/3.9.5/lib/python3.9/importlib/__init__.py:127: in import_module
return _bootstrap._gcd_import(name[level:], package, level)
/home/andrei/python/pytest/qa2/tests/test_psum.py:1: in
???
E ModuleNotFoundError: No module named ‘psum’
======================================================= short test summary info ========================================================
ERROR test_psum.py
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Interrupted: 1 error during collection !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
=========================================================== 1 error in 0.06s ===========================================================

То есть вместо

python -m pytest test_something.py

Выполните

cd ..

python -m pytest tests/test_something.py

NameError: name ‘pytest’ is not defined

Нужно импортировать pytest.

import pytest

Interrupted: 1 error during collection, SystemExit: 0 #9862

Code on Lib/_sitebuiltins.py :

Related: #8986 warn when the cmdline_main hook raises systemexit

The text was updated successfully, but these errors were encountered:

your test.py is being imported by pytest causing the collection error.

change your code to:

though you probably don’t want to always exit(0) but instead use pytest’s exit code

Thanks. It looks like I did not pay proper attention to the documentation example. Perhaps a note explaining why it has to be protected by if __name__ == ‘__main__’ would be nice for beginners like myself.

the example code does include that

As I can see, it only uses if __name__ == ‘__main__’ idiom. It does not say it is required to follow it.

sure — but I don’t think it’s necessary to write a code example and then tell the user to follow it — if the user decides to deviate from the example code that’s on them

Not sure that makes 100% sense. Example codes are made to be deviated from. Otherwise you would just be coding the example. Explanations for beginners should be totally concise and make it clear what is needed in the snippet. I’ve seen so many examples online that muddy the water with unnecessary stuff and as a newbie it can be tiring to fathom out what is relevant.

All learning and training starts with replication and the divergence happens as skill and understanding grows,

Going straight to divergence without understanding or a experimental base for exploration is a bit like a fresh Mason putting bricks in weird angles for giggles

It’s all to easy to end up with a train wreck because something was missed

© 2023 GitHub, Inc.

You can’t perform that action at this time.

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.

Источник

Ошибки PyTest

ImportError while importing test module

========================================================= test session starts ========================================================== platform linux — Python 3.9.5, pytest-7.0.1, pluggy-1.0.0 rootdir: /home/andrei/python/pytest/app/tests collected 0 items / 1 error ================================================================ ERRORS ================================================================ ____________________________________________________ ERROR collecting test_psum.py _____________________________________________________ ImportError while importing test module ‘/home/andrei/python/pytest/app/tests/test_psum.py’. Hint: make sure your test modules/packages have valid Python names. Traceback: ../../../../.pyenv/versions/3.9.5/lib/python3.9/importlib/__init__.py:127: in import_module return _bootstrap._gcd_import(name[level:], package, level) /home/andrei/python/pytest/qa2/tests/test_psum.py:1: in . E ModuleNotFoundError: No module named ‘psum’ ======================================================= short test summary info ======================================================== ERROR test_psum.py . Interrupted: 1 error during collection . =========================================================== 1 error in 0.06s ===========================================================

Такая ошибка может возникнуть если тест лежит в одтельной директории, например tests, и запущен оттуда же, но импорт тестируемого модуля сделан самым простым способом — просто как from mod1 import fun1

PyTest не может найти модуль, который нужно протестировать. Скорее всего поможет запуск теста из корневой директории.

Источник

Pytest не может импортировать модуль, в то время как Python может

Я работаю над пакетом в Python. Я использую virtualenv. Я установил путь к корню модуля в пути .pth в моем virtualenv, чтобы я мог импортировать модули пакета во время разработки кода и проводить тестирование (Вопрос 1: это хороший способ сделать?). Это прекрасно работает (вот пример, это поведение, которое я хочу):

Однако, если я пытаюсь использовать PyTest, я получаю несколько сообщений об ошибках импорта:

Я немного озадачен, похоже, это указывает на ошибку импорта, но Python делает это хорошо, так почему есть проблема именно с PyTest? Любое предложение по причине / средствам защиты (Вопрос 2)? Я погуглил и переполнил стек «Ошибка ImportError: не могу импортировать» для PyTest, но полученные мной попадания были связаны с отсутствием пути к питону и исправлением этой проблемы, которая, по-видимому, здесь не является проблемой. Какие-либо предложения?

20 ответов

НЕ помещайте файл __init__.py в папку, содержащую ИСПЫТАНИЯ, если вы планируете использовать pytest. У меня был один такой файл, удаление которого решило проблему.

Это было на самом деле скрыто в комментариях ко второму ответу на проблему PATH с pytest ‘ImportError: нет модуля с именем YadaYadaYada’, поэтому я его не видел, надеюсь, он получит больше видимости здесь.

Отредактируйте ваш conftest.py и добавьте следующие строки кода:

И если вы пытаетесь запустить тестовый пример через терминал, используйте следующую команду ex:

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

Если у вас уже есть файлы .pyc, попробуйте удалить их.

Сегодня я сталкиваюсь с этой проблемой, вот что произошло:

Сначала я запускаю pytest в mac (это сгенерирует pyc-файлы), затем я запускаю докер-контейнер (os является alpine) с монтированным проектом dir, а затем, когда я пытаюсь запустить pytest в контейнере, происходит ImportError. после очистки всех pyc файлов ошибок больше нет.

Надеюсь, это может быть полезно.

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

В папке , где установлен pytest , перейдите в папку pytest-env .

Откройте файл pyvenv.cfg .

В файле измените include-system-site-packages с false на true .

Надеюсь, что это работает. Не забудьте проголосовать.

Возможно, что Pytest не читает пакет как модуль Python, в то время как Python (вероятно, из-за проблем с путями). Попробуйте изменить каталог скрипта pytest или явно добавить модуль в PYTHONPATH.

Или может быть, что на вашем компьютере установлены две версии Python. Проверьте исходный код Python на наличие pytest и на наличие оболочки python, которую вы запускаете. Если они отличаются (то есть Python 2 против 3), используйте source activate , чтобы убедиться, что вы запускаете pytest, установленный для того же питона, в котором установлен модуль.

Я столкнулся с этой проблемой сегодня и решил ее, вызвав python -m pytest из корневого каталога моего проекта.

Вызов pytest из того же места по-прежнему вызывал проблемы.

Мой проект DIR организован как:

Модуль routes был импортирован в мой test_routes.py как: from server.routes.routes import Routes

Надеюсь, это поможет!

Я получил это с помощью VSCode. У меня есть среда Конда. Я не думаю, что расширение Python VScode могло видеть обновления, которые я делал.

Я должен был бежать pip install ./ —upgrade

Если это связано с кодом Python, который был первоначально разработан в Python 2.7 и теперь мигрировал в Python 3.x, то проблема, вероятно, связана с проблемой импорта.

Например при импорте объекта из файла: base , который находится в том же каталоге, это будет работать в python 2.x:

В Python 3.x вы должны заменить полный путь base или .base невыполнение этого вызовет вышеуказанную проблему. поэтому постарайтесь:

У меня была похожая проблема, и она работала, когда я добавил файл init .py в каталог тестов.

Еще один особый случай:

У меня была проблема с использованием токсинов. Так что моя программа работала нормально, но юнит-тесты через токсины продолжали жаловаться. После установки пакетов (необходимых для программы) вам необходимо дополнительно указать пакеты, используемые в unittests, в tox.ini

[ Решено ] Прежде чем перейти непосредственно к решению удаления / добавления __init__.py , мы могли бы также посмотреть, как выполняется импорт в ваших классах. На самом деле, я потерял день, играя с одним __init__.py , думая, что это может быть проблемой 🙂 Однако, это было довольно информативно.

В моем случае это был неправильный способ вызова классов из одного класса python в другой класс python, который выбрасывал ImportError . Исправлен способ вызова классов / модулей, и он работал как шарм. Надеюсь, это поможет и другим.

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

Ответ выше не работает для меня. Я просто решил эту проблему, добавив абсолютный путь к модулю, который не найден, к sys.path в верхней части test_xxx.py (вашего тестового модуля), например:

В моем случае произошла ошибка импорта, поскольку пакет указывает на другой пакет / каталог с тем же именем , а его путь находится на один уровень выше папки, которую я на самом деле хотел. Я думаю, это также объясняет, почему некоторым людям нужно удалить _ init _.py, в то время как другим нужно добавить обратно.

Я просто поместил print(the_root_package.__path__) (после import the_root_package ) в консоли python и pytest , чтобы сравнить разницу

НИЖНЯЯ ЛИНИЯ: Когда вы делаете python , пакет, который вы импортируете, может отличаться от пакета, когда вы запускаете pytest .

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

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

sudo pip install ./ —upgrade

После установки обновленного модуля запуск Pytest дал правильные результаты (потому что я использовал правильную базу кода).

Эта проблема произойдет, если у вас есть tests.py файл и папка с тестами tests/__init__.py .

Во время сбора pytest находит папку, но когда она пытается импортировать тестовые файлы из папки, файл tests.py вызовет проблему с импортом.

Для исправления просто удалите файл tests.py и поместите все свои тесты в папку tests/ .

Для вашего конкретного случая исправление будет точно:

• Удалить файл /home/zz/Desktop/GitFolders/rc/tests.py
• Убедитесь, что /home/zz/Desktop/GitFolders/rc/tests/__init__.py присутствует

У меня была та же проблема, но по другой причине, чем упомянутые:

Я установил py.test глобально, а пакеты были установлены в виртуальной среде.

Решением было установить pytest в виртуальной среде. (Если ваша оболочка хэширует исполняемые файлы, как это делает Bash, используйте hash -r или используйте полный путь к py.test )

Я только что решил эту проблему, удалив __init__.py в корне моего проекта:

Не могу сказать, что понимаю, почему это работает, но у меня была та же проблема, и тесты работают нормально, если я запускаю python -m pytest .

Я в virtualenv, с pytest, также доступным по всему миру:

Источник

Python Testing с pytest. Конфигурация, ГЛАВА 6

Вернуться Дальше

В этой главе мы рассмотрим файлы конфигурации, которые влияют на pytest, обсудим, как pytest изменяет свое поведение на их основе, и внесем некоторые изменения в файлы конфигурации проекта Tasks.

Примеры в этой книге написаны с использованием Python 3.6 и pytest 3.2. pytest 3.2 поддерживает Python 2.6, 2.7 и Python 3.3+.

Исходный код для проекта Tasks, а также для всех тестов, показанных в этой книге, доступен по ссылке на веб-странице книги в pragprog.com. Вам не нужно загружать исходный код, чтобы понять тестовый код; тестовый код представлен в удобной форме в примерах. Но что бы следовать вместе с задачами проекта, или адаптировать примеры тестирования для проверки своего собственного проекта (руки у вас развязаны!), вы должны перейти на веб-страницу книги и скачать работу. Там же, на веб-странице книги есть ссылка для сообщений errata и дискуссионный форум.

Под спойлером приведен список статей этой серии.

Конфигурация

До сих пор в этой книге я говорил о различных нетестовых файлах, которые влияют на pytest в основном мимоходом, за исключением conftest.py, который я довольно подробно рассмотрел в главе 5, Плагины, на странице 95. В этой главе мы рассмотрим файлы конфигурации, которые влияют на pytest, обсудим, как pytest изменяет свое поведение на их основе, и внесем некоторые изменения в файлы конфигурации проекта Tasks.

Понимание файлов конфигурации pytest

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

Следует знать следующее:

• pytest.ini: Это основной файл конфигурации Pytest, который позволяет вам изменить поведение по умолчанию. Поскольку вы можете внести довольно много изменений в конфигурацию, большая часть этой главы посвящена настройкам, которые вы можете сделать в pytest.ini .
• conftest.py: Это локальный плагин, позволяющий подключать хук-функции и фикстуры для каталога, в котором существует файл conftest.py , и всех его подкаталогов. Файл conftest.py описан в главе 5 «Плагины» на стр. 95.
• __init__.py : При помещении в каждый test-подкаталог этот файл позволяет вам иметь идентичные имена test-файлов в нескольких каталогах test. Мы рассмотрим пример того, что пойдет не так без файлов __init__.py в тестовых каталогах в статье «Избегание коллизий имен файлов» на стр. 120.

Если вы используете tox, вас заинтересует:

• tox.ini: Этот файл похож на pytest.ini , но для tox . Однако вы можете разместить здесь свою конфигурацию pytest вместо того, чтобы иметь и файл tox.ini , и файл pytest.ini , сохраняя вам один файл конфигурации. Tox рассматривается в главе 7, «Использование pytest с другими инструментами», на стр. 125.

Если вы хотите распространять пакет Python (например, Tasks), этот файл будет интересен:

• setup.cfg: Это также файл в формате INI, который влияет на поведение файла setup.py . Можно добавить несколько строк в setup.py для запуска python setup.py test и запустить все ваши тесты pytest. Если вы распространяете пакет, возможно, у вас уже есть файл setup.cfg , и вы можете использовать этот файл для хранения конфигурации Pytest. Вы увидите, как это делается в Приложении 4, «Упаковка и распространение проектов Python», на стр. 175.

Независимо от того, в какой файл вы поместили конфигурацию pytest, формат будет в основном одинаковым.

Единственное отличие состоит в том, что заголовок раздела для setup.cfg — это [tool:pytest] вместо [pytest] .

List the Valid ini-file Options with pytest –help

Вы можете получить список всех допустимых параметров для pytest.ini из pytest —help :

Вы увидите все эти настройки в этой главе, за исключением doctest_optionflags , который рассматривается в главе 7, «Использование pytest с другими инструментами», на странице 125.

Плагины могут добавлять опции ini-файлов

Предыдущий список настроек не является константой. Для плагинов (и файлов conftest.py) возможно добавить опции файла ini. Добавленные опции также будут добавлены в вывод команды pytest —help.
Теперь давайте рассмотрим некоторые изменения конфигурации, которые мы можем внести с помощью встроенных настроек INI-файла, доступных в core pytest.

Изменение параметров командной строки по умолчанию

Вы использовали уже некоторые параметры командной строки для pytest, таких как -v/—verbose для подробного вывода -l/—showlocals для просмотра локальных переменных с трассировкой стека для неудачных тестов. Вы можете обнаружить, что всегда используете некоторые из этих options—or и предпочитаете использовать them—for a project . Если вы устанавливаете addopts в pytest.ini для нужных вам параметров, то вам больше не придется вводить их. Вот набор, который мне нравится:

Ключ -rsxX дает установку pytest сообщать о причинах всех skipped , xfailed или xpassed тестов. Ключ -l позволит pytest вывести трассировку стека для локальных переменных в случае каждого сбоя. —tb=short удалит большую часть трассировки стека. Однако, оставит файл и номер строки. Параметр —strict запрещает использование маркеров, если они не зарегистрированы в файле конфигурации. Вы увидите, как это сделать в следующем разделе.

Регистрация маркеров, чтобы избежать опечаток маркера

Пользовательские маркеры, как описано в разделе «Маркировка тестовых функций» на странице 31, отлично подходят для того, чтобы позволить вам пометить подмножество тестов для запуска определенным маркером. Тем не менее, слишком легко ошибиться в маркере и в конечном итоге некоторые тесты помечены @pytest.mark.smoke , а некоторые отмечены @pytest.mark.somke . По умолчанию это не ошибка. pytest просто думает, что вы создали два маркера. Однако это можно исправить, зарегистрировав маркеры в pytest.ini, например так:

Зарегистрировав эти маркеры, вы теперь также можете увидеть их с помощью pytest —markers с их описаниями:

Если маркеры не зарегистрированы, они не будут отображаться в списке —markers . Когда они зарегистрированы, они отображаются в списке, и если вы используете —strict , любые маркеры с ошибками или незарегистрированные отображаются как ошибки. Единственная разница между ch6/a/tasks_proj и ch6/b/tasks_proj заключается в содержимом файла pytest.ini. В ch6/a пусто. Давайте попробуем запустить тесты без регистрации каких-либо маркеров:

If you use markers in pytest.ini to register your markers, you may as well add —strict to your addopts while you’re at it. You’ll thank me later. Let’s go ahead and add a pytest.ini file to the tasks project:

Если вы используете маркеры в pytest.ini для регистрации своих маркеров, вы также можете добавить —strict к своим addopts . Ты поблагодаришь меня позже. Давайте продолжим и добавим файл pytest.ini в проект задач:

Если вы используете маркеры в pytest.ini для регистрации маркеров, вы можете также добавить —strict к имеющимся при помощи addopts . Круто?! Отложим благодарности и добавим файл pytest.ini в проект tasks :

Здесь комбинация флагов предпочитаемые по умолчанию:

• -rsxX , чтобы сообщить, какие тесты skipped, xfailed, или xpassed,
• —tb = short для более короткой трассировки при сбоях,
• —strict что бы разрешить только объявленные маркеры.
  И список маркеров для проекта.

Это должно позволить нам проводить тесты, в том числе дымовые(smoke tests):

Требование минимальной версии Pytest

Параметр minversion позволяет указать минимальную версию pytest, ожидаемую для тестов. Например, я задумал использовать approx() при тестировании чисел с плавающей запятой для определения “достаточно близкого” равенства в тестах. Но эта функция не была введена в pytest до версии 3.0. Чтобы избежать путаницы, я добавляю следующее в проекты, которые используют approx() :

Таким образом, если кто-то пытается запустить тесты, используя более старую версию pytest, появится сообщение об ошибке.

Остановка pytest от поиска в неправильных местах

Знаете ли вы, что одно из определений «recurse» заключается в том, что бы дважды выругаться в собственом коде? Ну, нет. На самом деле, это означает учет подкаталогов. pytest включит обнаружение тестов рекурсивно исследуя кучу каталогов. Но есть некоторые каталоги, которые вы хотите исключить из просмотра pytest.

Значением по умолчанию для norecurse является ‘. * Build dist CVS _darcs and *.egg. Having ‘.*’ — это хорошая причина назвать вашу виртуальную среду ‘.venv’, потому что все каталоги, начинающиеся с точки, не будут видны.

В случае проекта Tasks, не помешает указать src , потому что поиск в тестовых файлах с помощью pytest будет пустой тратой времени.

При переопределении параметра, который уже имеет полезное значение, такого как этот параметр, полезно знать, какие есть значения по умолчанию, и вернуть те, которые вам нужны, как я делал в предыдущем коде с *.egg dist build .
norecursedirs — своего рода следствие для тестовых путей, поэтому давайте посмотрим на это позже.

спецификация дерева тестового каталога

В то время как norecursedirs указывает pytest куда не надо заглядыывать, testpaths говорит pytest, где искать. testspaths — это список каталогов относительно корневого каталога для поиска тестов. Он используется только в том случае, если в качестве аргумента не указан каталог, файл или nodeid .

Предположим, что для проекта Tasks мы поместили pytest.ini в каталог tasks_proj вместо тестов:

Тогда может иметь смысл поместить тесты в testpaths :

Теперь, если вы запускаете pytest из каталога tasks_proj , pytest будет искать только в tasks_proj/tests . Проблема здесь в том, что во время разработки и отладки тестов я часто перебираю тестовый каталог, поэтому я могу легко тестировать подкаталог или файл, не указывая весь путь. Поэтому мне этот параметр мало помогает в интерактивном тестировании.

Тем не менее, он отлично подходит для тестов, запускаемых с сервера непрерывной интеграции или с tox-а. В этих случаях вы знаете, что корневой каталог будет фиксированным, и вы можете перечислить каталоги относительно этого фиксированного корневого каталога. Это также те случаи, когда вы действительно хотите сократить время тестирования, так что избавиться от поиска тестов — это здорово.

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

Изменение Правил Обнаружения Тестов

pytest находит тесты для запуска на основе определенных правил обнаружения тестов. Стандартные правила обнаружения тестов:

• Начните с одного или нескольких каталогов. Вы можете указать имена файлов или каталогов в командной строке. Если вы ничего не указали, используется текущий каталог.
• Искать в каталоге и во всех его подкаталогах тестовые модули.
• Тестовый модуль — это файл с именем, похожим на test_*.py или *_test.py .
• Посмотрите в тестовых модулях функции, которые начинаются с test.
• Ищите классы, которые начинаются с Test. Ищите методы в тех классах, которые начинаются с `test , но не имеют метода init`.

Это стандартные правила обнаружения; Однако вы можете изменить их.

python_classes

Обычное правило обнаружения тестов для pytest и классов — считать класс потенциальным тестовым классом, если он начинается с Test* . Класс также не может иметь метод __init__() . Но что, если мы захотим назвать наши тестовые классы как Test или Suite ? Вот где приходит python_classes :

Это позволяет нам называть классы так:

python_files

Как и pytest_classes , python_files изменяет правило обнаружения тестов по умолчанию, которое заключается в поиске файлов, начинающихся с test_* или имеющих в конце *_test .
Допустим, у вас есть пользовательский тестовый фреймворк, в котором вы назвали все свои тестовые файлы check_ .py . Кажется разумным. Вместо того, чтобы переименовывать все ваши файлы, просто добавьте строку в pytest.ini следующим образом:

Очень просто. Теперь вы можете постепенно перенести соглашение об именах, если хотите, или просто оставить его как check_* .

python_functions

python_functions действует как две предыдущие настройки, но для тестовых функций и имен методов. Значение по умолчанию — test_* . А чтобы добавить check_* —вы угадали—сделайте это:

Соглашения об именах pytest не кажутся такими уж ограничивающими, не так ли? Так что, если вам не нравится соглашение об именах по умолчанию, просто измените его. Тем не менее, я призываю вас иметь более вескую причину для таких решений. Миграция сотен тестовых файлов — определенно веская причина.

Запрет XPASS

Установка xfail_strict = true приводит к тому, что тесты, помеченные @pytest.mark.xfail , не распознаются, как вызвавшие ошибку. Я думаю, что эта установка должно быть всегда. Дополнительные сведения о маркере xfail см. В разделе «Маркировка тестов ожидающих сбоя» на стр. 37.

Предотвращение конфликтов имен файлов

Полезность наличия файла __init__.py в каждом тестовом подкаталоге проекта долго меня смущали. Однако разница между тем, чтобы иметь их или не иметь, проста. Если у вас есть файлы __init__.py во всех ваших тестовых подкаталогах, вы можете иметь одно и то же тестовое имя файла в нескольких каталогах. А если нет, то так сделать не получится.

Вот пример. Каталог a и b оба имеют файл test_foo.py . Неважно, что эти файлы содержат в себе, но для этого примера они выглядят так:

ch6/dups/b/test_foo.py

С такой структурой каталогов:

Эти файлы даже не имеют того же контента, но тесты испорчены. Запускать их по отдельности получится, а запустить pytest из каталога dups нет:

Ни чего не понятно!
Это сообщение об ошибке не дает понять, что пошло не так.

Чтобы исправить этот тест, просто добавьте пустой __init__.py файл в подкаталоги. Вот пример каталога dups_fixed такими же дублированными именами файлов, но с добавленными файлами __init__.py :

Теперь давайте попробуем еще раз с верхнего уровня в dups_fixed :

Так то будет лучше.

Вы, конечно, можете убеждать себя, что у вас никогда не будет повторяющихся имен файлов, поэтому это не имеет значения. Все, типа, нормально. Но проекты растут и тестовые каталоги растут, и вы точно хотите дождаться, когда это случиться с вами, прежде чем позаботиться об этом? Я говорю, просто положите эти файлы туда. Сделайте это привычкой и не беспокойтесь об этом снова.

Упражнения

In Chapter 5, Plugins, on page 95, you created a plugin called pytest-nice that included a —nice command-line option. Let’s extend that to include a pytest.ini option called nice.

В главе 5 «Плагины» на стр. 95 вы создали плагин с именем pytest-nice который включает параметр командной строки —nice . Давайте расширим это, включив опцию pytest.ini под названием nice .

1. Добавьте следующую строку в хук-функцию pytest_addoption pytest_nice.py : parser.addini(‘nice’, type=’bool’, help=’Turn failures into opportunities.’)
2. Места в плагине, которые используют getoption() , также должны будут вызывать getini(‘nice’) . Сделайте эти изменения.
3. Проверьте это вручную, добавив nice в файл pytest.ini .
4. Не забудьте про тесты плагинов. Добавьте тест, чтобы убедиться, что параметр nice из pytest.ini работает корректно.
5. Добавьте тесты в каталог плагинов. Вам нужно найти некоторые дополнительные функции Pytester.

Что дальше

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

Вернуться Дальше

Источник

(VEnvTestRc) zz@zz:~/Desktop/GitFolders/rc$ python
Python 2.7.12 (default, Jul  1 2016, 15:12:24) 
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from rc import ns
>>> exit()
(VEnvTestRc) zz@zz:~/Desktop/GitFolders/rc$ python tests/test_ns.py 
issued command: echo hello
command output: hello

(VEnvTestRc) zz@zz:~/Desktop/GitFolders/rc$ pytest
=========================================== test session starts ============================================
platform linux2 -- Python 2.7.12, pytest-3.0.5, py-1.4.31, pluggy-0.4.0
rootdir: /home/zz/Desktop/GitFolders/rc, inifile: 
collected 0 items / 1 errors 

================================================== ERRORS ==================================================
________________________________ ERROR collecting tests/test_ns.py ________________________________
ImportError while importing test module '/home/zz/Desktop/GitFolders/rc/tests/test_ns.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
tests/test_ns.py:2: in <module>
    from rc import ns
E   ImportError: cannot import name ns
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Interrupted: 1 errors during collection !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
========================================= 1 error in 0.09 seconds ==========================================
(VEnvTestRc) zz@zz:~/Desktop/GitFolders/rc$ which pytest
/home/zz/Desktop/VirtualEnvs/VEnvTestRc/bin/pytest

20 ответов

Лучший ответ

import os, sys
sys.path.insert(0, os.path.abspath(os.path.join(os.path.dirname(file), '..')))

python -m pytest test_some_step_file_steps.py --html=HTML_step_file_output.html --self-contained-html

home = /usr/bin
include-system-site-packages = true
version = 3.6.6

api/
 - server/
  - tests/
      - test_routes.py
  - routes/
      - routes.py
 - app.py

python c:Usersbrig.vscodeextensionsms-python.python-2019.9.34911pythonFilestesting_toolsrun_adapter.py discover pytest -- -s --cache-clear test
Test Discovery failed:

from base import MyClass

from .base import MyClass

[testenv]
deps =
    package1
    package2 
...

import sys
sys.path.append('path')

.
├── __init__.py <--- removed
├── models
│   ├── __init__.py
│   ├── address.py
│   ├── appointment.py
│   └── client.py
├── requirements.txt
├── setup.cfg
├── tests
│   ├── __init__.py
│   ├── models
│   │   ├── __init__.py
│   │   ├── appointment_test.py
│   │   └── client_test.py
│   └── other_test.py
└── script.py

(proj)tom@neon ~/dev/proj$ type -a python
python is /home/tom/.virtualenvs/proj/bin/python
python is /usr/bin/python

(proj)tom@neon ~/dev/proj$ python -V
Python 3.5.2

(proj)tom@neon ~/dev/proj$ type -a pytest
pytest is /home/tom/.virtualenvs/proj/bin/pytest
pytest is /usr/bin/pytest

(proj)tom@neon ~/dev/proj$ pytest --version
This is pytest version 3.5.0, imported from /home/tom/.virtualenvs/proj/lib/python3.5/site-packages/pytest.py

Вернуться Дальше

В этой главе мы рассмотрим файлы конфигурации, которые влияют на pytest, обсудим, как pytest изменяет свое поведение на их основе, и внесем некоторые изменения в файлы конфигурации проекта Tasks.

Примеры в этой книге написаны с использованием Python 3.6 и pytest 3.2. pytest 3.2 поддерживает Python 2.6, 2.7 и Python 3.3+.

Исходный код для проекта Tasks, а также для всех тестов, показанных в этой книге, доступен по ссылке на веб-странице книги в pragprog.com. Вам не нужно загружать исходный код, чтобы понять тестовый код; тестовый код представлен в удобной форме в примерах. Но что бы следовать вместе с задачами проекта, или адаптировать примеры тестирования для проверки своего собственного проекта (руки у вас развязаны!), вы должны перейти на веб-страницу книги и скачать работу. Там же, на веб-странице книги есть ссылка для сообщений errata и дискуссионный форум.

Под спойлером приведен список статей этой серии.

Конфигурация

До сих пор в этой книге я говорил о различных нетестовых файлах, которые влияют на pytest в основном мимоходом, за исключением conftest.py, который я довольно подробно рассмотрел в главе 5, Плагины, на странице 95. В этой главе мы рассмотрим файлы конфигурации, которые влияют на pytest, обсудим, как pytest изменяет свое поведение на их основе, и внесем некоторые изменения в файлы конфигурации проекта Tasks.

Понимание файлов конфигурации pytest

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

Следует знать следующее:

• pytest.ini: Это основной файл конфигурации Pytest, который позволяет вам изменить поведение по умолчанию. Поскольку вы можете внести довольно много изменений в конфигурацию, большая часть этой главы посвящена настройкам, которые вы можете сделать в pytest.ini.
• conftest.py: Это локальный плагин, позволяющий подключать хук-функции и фикстуры для каталога, в котором существует файл conftest.py, и всех его подкаталогов. Файл conftest.py описан в главе 5 «Плагины» на стр. 95.
• __init__.py: При помещении в каждый test-подкаталог этот файл позволяет вам иметь идентичные имена test-файлов в нескольких каталогах test. Мы рассмотрим пример того, что пойдет не так без файлов __init__.py в тестовых каталогах в статье «Избегание коллизий имен файлов» на стр. 120.

Если вы используете tox, вас заинтересует:

• tox.ini: Этот файл похож на pytest.ini, но для tox. Однако вы можете разместить здесь свою конфигурацию pytest вместо того, чтобы иметь и файл tox.ini, и файл pytest.ini, сохраняя вам один файл конфигурации. Tox рассматривается в главе 7, «Использование pytest с другими инструментами», на стр. 125.

Если вы хотите распространять пакет Python (например, Tasks), этот файл будет интересен:

• setup.cfg: Это также файл в формате INI, который влияет на поведение файла setup.py. Можно добавить несколько строк в setup.py для запуска python setup.py test и запустить все ваши тесты pytest. Если вы распространяете пакет, возможно, у вас уже есть файл setup.cfg, и вы можете использовать этот файл для хранения конфигурации Pytest. Вы увидите, как это делается в Приложении 4, «Упаковка и распространение проектов Python», на стр. 175.

Независимо от того, в какой файл вы поместили конфигурацию pytest, формат будет в основном одинаковым.

Для pytest.ini:

ch6/format/pytest.ini

[pytest]
addopts = -rsxX -l --tb=short --strict
xfail_strict = true
... more options ...

Для tox.ini:

ch6/format/tox.ini

... tox specific stuff ...
[pytest]
addopts = -rsxX -l --tb=short --strict
xfail_strict = true
... more options ...

Для setup.cfg:

ch6/format/setup.cfg

... packaging specific stuff ...
[tool:pytest]
addopts = -rsxX -l --tb=short --strict
xfail_strict = true
... more options ...

Единственное отличие состоит в том, что заголовок раздела для setup.cfg — это [tool:pytest] вместо [pytest].

List the Valid ini-file Options with pytest –help

Вы можете получить список всех допустимых параметров для pytest.ini из pytest --help:

$ pytest --help
...
[pytest] ini-options in the first pytest.ini|tox.ini|setup.cfg file found:                                                                 

  markers (linelist)       markers for test functions                                                                                      
  empty_parameter_set_mark (string) default marker for empty parametersets                                                                 
  norecursedirs (args)     directory patterns to avoid for recursion                                                                       
  testpaths (args)         directories to search for tests when no files or directories are given in the command line.                     
  console_output_style (string) console output: classic or with additional progress information (classic|progress).                        
  usefixtures (args)       list of default fixtures to be used with this project                                                           
  python_files (args)      glob-style file patterns for Python test module discovery                                                       
  python_classes (args)    prefixes or glob names for Python test class discovery                                                          
  python_functions (args)  prefixes or glob names for Python test function and method discovery                                            
  xfail_strict (bool)      default for the strict parameter of xfail markers when not given explicitly (default: False)                    
  junit_suite_name (string) Test suite name for JUnit report                                                                               
  junit_logging (string)   Write captured log messages to JUnit report: one of no|system-out|system-err                                    
  doctest_optionflags (args) option flags for doctests                                                                                     
  doctest_encoding (string) encoding used for doctest files                                                                                
  cache_dir (string)       cache directory path.                                                                                           
  filterwarnings (linelist) Each line specifies a pattern for warnings.filterwarnings. Processed after -W and --pythonwarnings.            
  log_print (bool)         default value for --no-print-logs                                                                               
  log_level (string)       default value for --log-level                                                                                   
  log_format (string)      default value for --log-format                                                                                  
  log_date_format (string) default value for --log-date-format                                                                             
  log_cli (bool)           enable log display during test run (also known as "live logging").                                              
  log_cli_level (string)   default value for --log-cli-level                                                                               
  log_cli_format (string)  default value for --log-cli-format                                                                              
  log_cli_date_format (string) default value for --log-cli-date-format                                                                     
  log_file (string)        default value for --log-file                                                                                    
  log_file_level (string)  default value for --log-file-level                                                                              
  log_file_format (string) default value for --log-file-format                                                                             
  log_file_date_format (string) default value for --log-file-date-format                                                                   
  addopts (args)           extra command line options                                                                                      
  minversion (string)      minimally required pytest version                                                                               
  xvfb_width (string)      Width of the Xvfb display                                                                                       
  xvfb_height (string)     Height of the Xvfb display                                                                                      
  xvfb_colordepth (string) Color depth of the Xvfb display                                                                                 
  xvfb_args (args)         Additional arguments for Xvfb                                                                                   
  xvfb_xauth (bool)        Generate an Xauthority token for Xvfb. Needs xauth. 

...

Вы увидите все эти настройки в этой главе, за исключением doctest_optionflags, который рассматривается в главе 7, «Использование pytest с другими инструментами», на странице 125.

Плагины могут добавлять опции ini-файлов

Предыдущий список настроек не является константой. Для плагинов (и файлов conftest.py) возможно добавить опции файла ini. Добавленные опции также будут добавлены в вывод команды pytest —help.
Теперь давайте рассмотрим некоторые изменения конфигурации, которые мы можем внести с помощью встроенных настроек INI-файла, доступных в core pytest.

Изменение параметров командной строки по умолчанию

Вы использовали уже некоторые параметры командной строки для pytest, таких как -v/--verbose для подробного вывода -l/--showlocals для просмотра локальных переменных с трассировкой стека для неудачных тестов. Вы можете обнаружить, что всегда используете некоторые из этих options—or и предпочитаете использовать them—for a project. Если вы устанавливаете addopts в pytest.ini для нужных вам параметров, то вам больше не придется вводить их. Вот набор, который мне нравится:

[pytest]
addopts = -rsxX -l --tb=short --strict

Ключ -rsxX дает установку pytest сообщать о причинах всех skipped, xfailed или xpassed тестов. Ключ -l позволит pytest вывести трассировку стека для локальных переменных в случае каждого сбоя. --tb=short удалит большую часть трассировки стека. Однако, оставит файл и номер строки. Параметр --strict запрещает использование маркеров, если они не зарегистрированы в файле конфигурации. Вы увидите, как это сделать в следующем разделе.

Регистрация маркеров, чтобы избежать опечаток маркера

Пользовательские маркеры, как описано в разделе «Маркировка тестовых функций» на странице 31, отлично подходят для того, чтобы позволить вам пометить подмножество тестов для запуска определенным маркером. Тем не менее, слишком легко ошибиться в маркере и в конечном итоге некоторые тесты помечены @pytest.mark.smoke, а некоторые отмечены @pytest.mark.somke. По умолчанию это не ошибка. pytest просто думает, что вы создали два маркера. Однако это можно исправить, зарегистрировав маркеры в pytest.ini, например так:

[pytest]
...
markers = 
  smoke: Run the smoke test test functions
  get: Run the test functions that test tasks.get()
...

Зарегистрировав эти маркеры, вы теперь также можете увидеть их с помощью pytest --markers с их описаниями:

$ cd /path/to/code/ch6/b/tasks_proj/tests
$ pytest --markers

@pytest.mark.smoke: Run the smoke test test functions

@pytest.mark.get: Run the test functions that test tasks.get()

@pytest.mark.skip(reason=None): skip the ...

...

Если маркеры не зарегистрированы, они не будут отображаться в списке --markers. Когда они зарегистрированы, они отображаются в списке, и если вы используете --strict, любые маркеры с ошибками или незарегистрированные отображаются как ошибки. Единственная разница между ch6/a/tasks_proj и ch6/b/tasks_proj заключается в содержимом файла pytest.ini. В ch6/a пусто. Давайте попробуем запустить тесты без регистрации каких-либо маркеров:

$ cd /path/to/code/ch6/a/tasks_proj/tests
$ pytest --strict --tb=line

============================= test session starts =============================

collected 45 items / 2 errors

=================================== ERRORS ====================================
______________________ ERROR collecting func/test_add.py ______________________
'smoke' not a registered marker
________________ ERROR collecting func/test_api_exceptions.py _________________
'smoke' not a registered marker
!!!!!!!!!!!!!!!!!!! Interrupted: 2 errors during collection !!!!!!!!!!!!!!!!!!!
=========================== 2 error in 1.10 seconds ===========================

If you use markers in pytest.ini to register your markers, you may as well add --strict to your addopts while you’re at it. You’ll thank me later. Let’s go ahead and add a pytest.ini file to the tasks project:

Если вы используете маркеры в pytest.ini для регистрации своих маркеров, вы также можете добавить --strict к своим addopts. Ты поблагодаришь меня позже. Давайте продолжим и добавим файл pytest.ini в проект задач:

Если вы используете маркеры в pytest.ini для регистрации маркеров, вы можете также добавить --strict к имеющимся при помощи addopts. Круто?! Отложим благодарности и добавим файл pytest.ini в проект tasks:

ch6/b/tasks_proj/tests/pytest.ini

[pytest]
addopts = -rsxX -l --tb=short --strict
markers =
  smoke: Run the smoke test test functions
  get: Run the test functions that test tasks.get()

Здесь комбинация флагов предпочитаемые по умолчанию:

• -rsxX, чтобы сообщить, какие тесты skipped, xfailed, или xpassed,
• --tb = short для более короткой трассировки при сбоях,
• --strict что бы разрешить только объявленные маркеры.
  И список маркеров для проекта.

Это должно позволить нам проводить тесты, в том числе дымовые(smoke tests):

$ cd /path/to/code/ch6/b/tasks_proj/tests
$ pytest --strict -m smoke

===================== test session starts ======================
collected 57 items

func/test_add.py .
func/test_api_exceptions.py ..

===================== 54 tests deselected ======================
=========== 3 passed, 54 deselected in 0.06 seconds ============ 

Требование минимальной версии Pytest

Параметр minversion позволяет указать минимальную версию pytest, ожидаемую для тестов. Например, я задумал использовать approx() при тестировании чисел с плавающей запятой для определения “достаточно близкого” равенства в тестах. Но эта функция не была введена в pytest до версии 3.0. Чтобы избежать путаницы, я добавляю следующее в проекты, которые используют approx():

[pytest]
minversion = 3.0

Таким образом, если кто-то пытается запустить тесты, используя более старую версию pytest, появится сообщение об ошибке.

Остановка pytest от поиска в неправильных местах

Знаете ли вы, что одно из определений «recurse» заключается в том, что бы дважды выругаться в собственом коде? Ну, нет. На самом деле, это означает учет подкаталогов. pytest включит обнаружение тестов рекурсивно исследуя кучу каталогов. Но есть некоторые каталоги, которые вы хотите исключить из просмотра pytest.

Значением по умолчанию для norecurse является '. * Build dist CVS _darcs {arch} and *.egg. Having '.*' — это хорошая причина назвать вашу виртуальную среду ‘.venv’, потому что все каталоги, начинающиеся с точки, не будут видны.

В случае проекта Tasks, не помешает указать src, потому что поиск в тестовых файлах с помощью pytest будет пустой тратой времени.

[pytest]
norecursedirs = .* venv src *.egg dist build

При переопределении параметра, который уже имеет полезное значение, такого как этот параметр, полезно знать, какие есть значения по умолчанию, и вернуть те, которые вам нужны, как я делал в предыдущем коде с *.egg dist build.
norecursedirs — своего рода следствие для тестовых путей, поэтому давайте посмотрим на это позже.

спецификация дерева тестового каталога

В то время как norecursedirs указывает pytest куда не надо заглядыывать, testpaths говорит pytest, где искать. testspaths — это список каталогов относительно корневого каталога для поиска тестов. Он используется только в том случае, если в качестве аргумента не указан каталог, файл или nodeid.

Предположим, что для проекта Tasks мы поместили pytest.ini в каталог tasks_proj вместо тестов:

codetasks_proj>tree/f
.
│   pytest.ini
│
├───src
│   └───tasks
│           api.py
│           ...
│
└───tests
    │   conftest.py
    │   pytest.ini
    │
    ├───func
    │       test_add.py
    │       ...
    │
    ├───unit
    │       test_task.py
    │       __init__.py
    │       ...

Тогда может иметь смысл поместить тесты в testpaths:

[pytest]
testpaths = tests

Теперь, если вы запускаете pytest из каталога tasks_proj, pytest будет искать только в tasks_proj/tests. Проблема здесь в том, что во время разработки и отладки тестов я часто перебираю тестовый каталог, поэтому я могу легко тестировать подкаталог или файл, не указывая весь путь. Поэтому мне этот параметр мало помогает в интерактивном тестировании.

Тем не менее, он отлично подходит для тестов, запускаемых с сервера непрерывной интеграции или с tox-а. В этих случаях вы знаете, что корневой каталог будет фиксированным, и вы можете перечислить каталоги относительно этого фиксированного корневого каталога. Это также те случаи, когда вы действительно хотите сократить время тестирования, так что избавиться от поиска тестов — это здорово.

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

Изменение Правил Обнаружения Тестов

pytest находит тесты для запуска на основе определенных правил обнаружения тестов. Стандартные правила обнаружения тестов:

• Начните с одного или нескольких каталогов. Вы можете указать имена файлов или каталогов в командной строке. Если вы ничего не указали, используется текущий каталог.
• Искать в каталоге и во всех его подкаталогах тестовые модули.
• Тестовый модуль — это файл с именем, похожим на test_*.py или *_test.py.
• Посмотрите в тестовых модулях функции, которые начинаются с test.
• Ищите классы, которые начинаются с Test. Ищите методы в тех классах, которые начинаются с `test, но не имеют методаinit`.

Это стандартные правила обнаружения; Однако вы можете изменить их.

python_classes

Обычное правило обнаружения тестов для pytest и классов — считать класс потенциальным тестовым классом, если он начинается с Test*. Класс также не может иметь метод __init__(). Но что, если мы захотим назвать наши тестовые классы как <something>Test или <something>Suite? Вот где приходит python_classes:

[pytest]
python_classes = *Test Test* *Suite

Это позволяет нам называть классы так:

class DeleteSuite():

    def test_delete_1():
        ...

    def test_delete_2():
        ...

    ....

python_files

Как и pytest_classes, python_files изменяет правило обнаружения тестов по умолчанию, которое заключается в поиске файлов, начинающихся с test_* или имеющих в конце *_test.
Допустим, у вас есть пользовательский тестовый фреймворк, в котором вы назвали все свои тестовые файлы check_<something>.py. Кажется разумным. Вместо того, чтобы переименовывать все ваши файлы, просто добавьте строку в pytest.ini следующим образом:

[pytest]
python_files = test_* *_test check_*

Очень просто. Теперь вы можете постепенно перенести соглашение об именах, если хотите, или просто оставить его как check_*.

python_functions

python_functions действует как две предыдущие настройки, но для тестовых функций и имен методов. Значение по умолчанию — test_*. А чтобы добавить check_*—вы угадали—сделайте это:

[pytest]
python_functions = test_*  check_*

Соглашения об именах pytest не кажутся такими уж ограничивающими, не так ли? Так что, если вам не нравится соглашение об именах по умолчанию, просто измените его. Тем не менее, я призываю вас иметь более вескую причину для таких решений. Миграция сотен тестовых файлов — определенно веская причина.

Запрет XPASS

Установка xfail_strict = true приводит к тому, что тесты, помеченные @pytest.mark.xfail, не распознаются, как вызвавшие ошибку. Я думаю, что эта установка должно быть всегда. Дополнительные сведения о маркере xfail см. В разделе «Маркировка тестов ожидающих сбоя» на стр. 37.

Предотвращение конфликтов имен файлов

Полезность наличия файла __init__.py в каждом тестовом подкаталоге проекта долго меня смущали. Однако разница между тем, чтобы иметь их или не иметь, проста. Если у вас есть файлы __init__.py во всех ваших тестовых подкаталогах, вы можете иметь одно и то же тестовое имя файла в нескольких каталогах. А если нет, то так сделать не получится.

Вот пример. Каталог a и b оба имеют файл test_foo.py. Неважно, что эти файлы содержат в себе, но для этого примера они выглядят так:

ch6/dups/a/test_foo.py

def test_a():
pass

ch6/dups/b/test_foo.py

def test_b():
pass

С такой структурой каталогов:

dups
├── a
│   └── test_foo.py
└── b
    └── test_foo.py

Эти файлы даже не имеют того же контента, но тесты испорчены. Запускать их по отдельности получится, а запустить pytest из каталога dups нет:

$ cd /path/to/code/ch6/dups
$ pytest a
============================= test session starts =============================

collected 1 item

atest_foo.py .                                                          

========================== 1 passed in 0.05 seconds ===========================

$ pytest b
============================= test session starts =============================

collected 1 item

btest_foo.py .                                                          

========================== 1 passed in 0.05 seconds ===========================

$ pytest
============================= test session starts =============================

collected 1 item / 1 errors

=================================== ERRORS ====================================
_______________________ ERROR collecting b/test_foo.py ________________________
import file mismatch:
imported module 'test_foo' has this __file__ attribute:
  /path/to/code/ch6/dups/a/test_foo.py
which is not the same as the test file we want to collect:
  /path/to/code/ch6/dups/b/test_foo.py
HINT: remove __pycache__ / .pyc files and/or use a unique basename for your test file modules
!!!!!!!!!!!!!!!!!!! Interrupted: 1 errors during collection !!!!!!!!!!!!!!!!!!!
=========================== 1 error in 0.34 seconds ===========================

Ни чего не понятно!
Это сообщение об ошибке не дает понять, что пошло не так.

Чтобы исправить этот тест, просто добавьте пустой __init__.py файл в подкаталоги. Вот пример каталога dups_fixed такими же дублированными именами файлов, но с добавленными файлами __init__.py:

dups_fixed/
├── a
│   ├── __init__.py
│   └── test_foo.py
└── b
    ├── __init__.py
    └── test_foo.py

Теперь давайте попробуем еще раз с верхнего уровня в dups_fixed:

$ cd /path/to/code/ch6/ch6/dups_fixed/

$ pytest
============================= test session starts =============================

collected 2 items

atest_foo.py .                                                          
btest_foo.py .                                                         

========================== 2 passed in 0.15 seconds ===========================

Так то будет лучше.

Вы, конечно, можете убеждать себя, что у вас никогда не будет повторяющихся имен файлов, поэтому это не имеет значения. Все, типа, нормально. Но проекты растут и тестовые каталоги растут, и вы точно хотите дождаться, когда это случиться с вами, прежде чем позаботиться об этом? Я говорю, просто положите эти файлы туда. Сделайте это привычкой и не беспокойтесь об этом снова.

Упражнения

In Chapter 5, Plugins, on page 95, you created a plugin called pytest-nice that included a —nice command-line option. Let’s extend that to include a pytest.ini option called nice.

В главе 5 «Плагины» на стр. 95 вы создали плагин с именем pytest-nice который включает параметр командной строки --nice. Давайте расширим это, включив опцию pytest.ini под названием nice.

1. Добавьте следующую строку в хук-функцию pytest_addoption pytest_nice.py: parser.addini('nice', type='bool', help='Turn failures into opportunities.')
2. Места в плагине, которые используют getoption(), также должны будут вызывать getini('nice'). Сделайте эти изменения.
3. Проверьте это вручную, добавив nice в файл pytest.ini.
4. Не забудьте про тесты плагинов. Добавьте тест, чтобы убедиться, что параметр nice из pytest.ini работает корректно.
5. Добавьте тесты в каталог плагинов. Вам нужно найти некоторые дополнительные функции Pytester.

Что дальше

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

Вернуться Дальше

Я работаю над пакетом на Python. Я использую virtualenv. Я устанавливаю путь к корню модуля в пути.pth в моем virtualenv, чтобы я мог импортировать модули пакета при разработке кода и тестировании (вопрос 1: это хороший способ сделать?). Это отлично работает (вот пример, это поведение, которое я хочу):

(VEnvTestRc) [email protected]:~/Desktop/GitFolders/rc$ python
Python 2.7.12 (default, Jul  1 2016, 15:12:24) 
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from rc import ns
>>> exit()
(VEnvTestRc) [email protected]:~/Desktop/GitFolders/rc$ python tests/test_ns.py 
issued command: echo hello
command output: hello

Однако, если я пытаюсь использовать PyTest, я получаю сообщения об ошибках импорта:

(VEnvTestRc) [email protected]:~/Desktop/GitFolders/rc$ pytest
=========================================== test session starts ============================================
platform linux2 -- Python 2.7.12, pytest-3.0.5, py-1.4.31, pluggy-0.4.0
rootdir: /home/zz/Desktop/GitFolders/rc, inifile: 
collected 0 items / 1 errors 

================================================== ERRORS ==================================================
________________________________ ERROR collecting tests/test_ns.py ________________________________
ImportError while importing test module '/home/zz/Desktop/GitFolders/rc/tests/test_ns.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
tests/test_ns.py:2: in <module>
    from rc import ns
E   ImportError: cannot import name ns
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Interrupted: 1 errors during collection !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
========================================= 1 error in 0.09 seconds ==========================================
(VEnvTestRc) [email protected]:~/Desktop/GitFolders/rc$ which pytest
/home/zz/Desktop/VirtualEnvs/VEnvTestRc/bin/pytest

Я немного озадачен, похоже, что это указывает на ошибку импорта, но Python делает это хорошо, так почему возникает проблема с PyTest? Любое предложение по причине/исправлению (вопрос 2)? Я googled и stack-overflowed ошибка «ImportError: не могу импортировать» для PyTest, но полученные мной хиты были связаны с отсутствием пути python и средством для этого, что, похоже, не является проблемой здесь. Какие-либо предложения?