Добавьте в файл conftest py обработчик который считывает из командной строки параметр language
Я использовал easy_install для установки pytest на mac и начал писать тесты для проекта с файловой структурой:
запустите py.test , в то время как в каталоге репо все ведет себя так, как вы ожидали.
но когда я пытаюсь сделать то же самое на linux или windows (оба имеют pytest 2.2.3 на них), он берется всякий раз, когда он начинает свой первый импорт чего-либо из моего пути к приложению. Скажем, например, from app import some_def_in_app
Нужно ли мне редактировать PATH для запуска py.test в этих системах? Кто-нибудь испытал это?
Да, исходная папка не находится в пути Python, если вы cd к каталогу тестов.
У вас есть 2 варианта:
Добавьте путь к тестовым файлам вручную, например:
Запустите тесты с помощью env var PYTHONPATH=../ .
Я не уверен, почему py.test не добавляет текущий каталог в сам PYTHONPATH, но здесь обходной путь (который должен выполняться из корня вашего репозитория):
Это работает, потому что Python добавляет текущий каталог в PYTHONPATH для вас.
У меня была та же проблема. Я исправил его, добавив пустой __init__.py файл в мой каталог tests .
Понимание файлов конфигурации 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] .
Как добавить атрибут к AsyncMock?
Код: class SomeClass(BaseClass): async def async_method(arg1, arg2, **kwargs): await self.foo.bar(arg1=arg1, arg2=arg2).baz(**kwargs) Один из нескольких используемых вариантов теста: @.
Как определить, запущено ли приложение из pytest ¶
Вообще-то, заставлять приложение вести себя по-другому при тестировании - плохая идея. Но если уж совершенно необходимо выяснить, запускается ли приложение из теста или нет, можно сделать как-то так:
И потом проверять флажок your_module._called_from_test :
в самом приложении
Django, Celery, Pytest и база данных
Есть например такой таск: @shared_task def do_something(): from django_app.models import TestModel TestModel(foo='foo').save() И есть например такой тест (для работы с БД в тестах .
Фикстуры уровня пакета/каталога (setups)¶
Если в вашем дереве тестов есть вложенные каталоги, можно каждый из них рассматривать как область действия фикстур - для этого достаточно разместить фикстуры в файле conftest.py соответствующего каталога. При этом можно использовать все типы фикстур, включая фикстуры autouse - аналоги setup/teardown функций xUnit Однако имейте в виду, что рекомендуется явно ссылаться на фикстуры в тестах и классах, вместо того, чтобы полагаться на неявное выполнение setup/teardown функций, особенно если они расположены далеко от использующих их тестов.
Вот пример, как сделать фикстуру db доступной в каталоге:
И тестовый модуль в этой же директории:
Еще один тестовый модуль:
А этот модуль расположен в соседней (сестринской) директории, и там фикстура db будет не видна:
Оба тестовых модуля из каталога a видят одну и ту же фикстуру db , а вот модуль из каталога b ее не видит. Конечно, мы можем так же определить фикстуру db в файле b/conftest.py . Обратите внимание, что каждая фикстура создается, только если требуется в тесте (кроме autouse фикстур - они всегда выполняются перед запуском тестов).
Изменение Правил Обнаружения Тестов
pytest находит тесты для запуска на основе определенных правил обнаружения тестов. Стандартные правила обнаружения тестов:
• Начните с одного или нескольких каталогов. Вы можете указать имена файлов или каталогов в командной строке. Если вы ничего не указали, используется текущий каталог.
• Искать в каталоге и во всех его подкаталогах тестовые модули.
• Тестовый модуль — это файл с именем, похожим на test_*.py или *_test.py .
• Посмотрите в тестовых модулях функции, которые начинаются с test.
• Ищите классы, которые начинаются с Test. Ищите методы в тех классах, которые начинаются с `test , но не имеют метода init`.
Это стандартные правила обнаружения; Однако вы можете изменить их.
Не работает session. Потеря контекста
Приведу несколько примеров. В одних случаях, я получаю ошибку вида: def __enter__(self) -> BaseTimerContext: task = current_task(loop=self._loop) if task is None: > .
Предотвращение конфликтов имен файлов
Полезность наличия файла __init__.py в каждом тестовом подкаталоге проекта долго меня смущали. Однако разница между тем, чтобы иметь их или не иметь, проста. Если у вас есть файлы __init__.py во всех ваших тестовых подкаталогах, вы можете иметь одно и то же тестовое имя файла в нескольких каталогах. А если нет, то так сделать не получится.
Вот пример. Каталог a и b оба имеют файл test_foo.py . Неважно, что эти файлы содержат в себе, но для этого примера они выглядят так:
ch6/dups/b/test_foo.py
С такой структурой каталогов:
Эти файлы даже не имеют того же контента, но тесты испорчены. Запускать их по отдельности получится, а запустить pytest из каталога dups нет:
Теперь давайте попробуем еще раз с верхнего уровня в dups_fixed :
Так то будет лучше.
Вы, конечно, можете убеждать себя, что у вас никогда не будет повторяющихся имен файлов, поэтому это не имеет значения. Все, типа, нормально. Но проекты растут и тестовые каталоги растут, и вы точно хотите дождаться, когда это случиться с вами, прежде чем позаботиться об этом? Я говорю, просто положите эти файлы туда. Сделайте это привычкой и не беспокойтесь об этом снова.
pytest allure. Генерация html отчета
Как скрыть в allure report передаваемые параметры(password)? Python+Pytest
Подскажите пожалуйста, я недавно в автотестировании, но столкнулся с следующим вопросом: allure report отображает password для используемых в тестах аккаунтов. Как можно скрыть передаваемые в запрос .
Конролируем пропуск тестов с помощью опции командной строки¶
Добавим в файл conftest.py опцию --runslow , чтобы контролировать пропуск тестов с пометкой pytest.mark.slow :
Можно теперь написать тестовый модуль:
Если запустим его, то «медленный» тест будет пропущен:
А теперь запустим и медленные тесты, применив нашу опцию --runslow :
Определение продолжительности выполнения тестов¶
Если у вас есть медленно выполняющийся огромный набор тестов, то может возникнуть желание выяснить, какие тесты самые медленные. Давайте создадим искусственный тестовый набор:
Теперь мы можем выяснить продолжительность трех самых медленных тестов с помощью --durations=3 :
Переменная окружения PYTEST_CURRENT_TEST ¶
Иногда тестовая сессия может зависнуть, и бывает непросто выяснить, на каком именно тесте она «застряла» (например, pytest запущен в «тихом» ( -q ) режиме или нет доступа к консольному выводу). Это особенно неприятно, когда проблема возникает нерегулярно - получаем так называемые «мерцающие» (flaky) тесты.
При запуске тестов pytest задает переменную окружения PYTEST_CURRENT_TEST , которую можно проверять с помощью утилит мониторинга процессов или библиотек вроде psutil для того, чтобы выяснить, какой именно тест «застрял»:
Во время тестовой сессии pytest будет присваивать PYTEST_CURRENT_TEST текущий идентификатор узла ( nodeid ) и текущее состояние: setup , call или teardown .
К примеру, если мы запустим одну тестовую функцию test_foo из модуля foo_module.py , PYTEST_CURRENT_TEST будет принимать следующие значения:
Именно в таком порядке.
Поскольку содержимое PYTEST_CURRENT_TEST должно быть читабельно, текущий формат от релиза к релизу может меняться (даже при фиксации багов), поэтому не стоит полагаться именно на такой вид при написании сценариев и автоматизации.
conftest решение
Наименее инвазивное решение – добавить пустой файл с именем conftest.py в conftest.py repo/ :
Это. Нет необходимости писать собственный код для искажения sys.path или не забывать перетаскивать PYTHONPATH вместе или помещать __init__.py в каталоги, где он не принадлежит.
Каталог проекта впоследствии:
Настройка __tracebackhide__ ¶
Настройка __tracebackhide__ влияет на то, ЧТО pytest выводит в трейсбэке: функция checkconfig не будет показана, пока в командной строке не будет применена опция --full-trace . Давайте запустим наш маленький тест:
Если вы хотите скрыть только определенные исключения, можно сопоставить __tracebackhide__ объект, который, в свою очередь, вернет объект ExceptionInfo . Это можно использовать, к примеру, для того чтобы убедиться, что неожиданные исключения будут отображены:
Такое решение позволит избежать скрытия в трассировке неожиданных исключений.
conftest решение
Наименее инвазивное решение – добавить пустой файл с именем conftest.py в conftest.py repo/ :
Это. Нет необходимости писать собственный код для искажения sys.path или не забывать перетаскивать PYTHONPATH вместе или помещать __init__.py в каталоги, где он не принадлежит.
Каталог проекта впоследствии:
Запрет XPASS
Установка xfail_strict = true приводит к тому, что тесты, помеченные @pytest.mark.xfail , не распознаются, как вызвавшие ошибку. Я думаю, что эта установка должно быть всегда. Дополнительные сведения о маркере xfail см. В разделе "Маркировка тестов ожидающих сбоя" на стр. 37.
Требование минимальной версии Pytest
Параметр minversion позволяет указать минимальную версию pytest, ожидаемую для тестов. Например, я задумал использовать approx() при тестировании чисел с плавающей запятой для определения “достаточно близкого” равенства в тестах. Но эта функция не была введена в pytest до версии 3.0. Чтобы избежать путаницы, я добавляю следующее в проекты, которые используют approx() :
Gitlab + pytest,selenium интеграция
Всем привет! На своей рабочей машине пишу и храню локально автотесты под веб. Есть гитлаб, следовательно создав джоб хочу их прогонять. Возможно ли сделать это, без докер образа?например в джобу .
Упражнения
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 .
- Добавьте следующую строку в хук-функцию pytest_addoption pytest_nice.py : parser.addini('nice', type='bool', help='Turn failures into opportunities.')
- Места в плагине, которые используют getoption() , также должны будут вызывать getini('nice') . Сделайте эти изменения.
- Проверьте это вручную, добавив nice в файл pytest.ini .
- Не забудьте про тесты плагинов. Добавьте тест, чтобы убедиться, что параметр nice из pytest.ini работает корректно.
- Добавьте тесты в каталог плагинов. Вам нужно найти некоторые дополнительные функции Pytester.
python_classes
Обычное правило обнаружения тестов для pytest и классов — считать класс потенциальным тестовым классом, если он начинается с Test* . Класс также не может иметь метод __init__() . Но что, если мы захотим назвать наши тестовые классы как Test или Suite ? Вот где приходит python_classes :
Это позволяет нам называть классы так:
Опции командной строки и настройки конфигурационного файла¶
Чтобы получить помощь по командной строке и настройкам конфигурационных файлов, используйте стандартную опцию -h :
Как сделать информацию о результатах тестов доступной для фикстуры¶
Если вы хотите, чтобы отчеты о результатах тестов были доступны в финализирующей фикстуре, можно реализовать следующий небольшой плагин:
Теперь, пусть у нас есть неудачные тесты:
Как видите, финализаторы могут использовать информацию из отчета.
Другие структуры проекта
Если у вас есть другая структура проекта, поместите conftest.py в корневой каталог пакета (тот, который содержит пакеты, но не сам пакет, поэтому не содержит __init__.py ), например:
Плагины могут добавлять опции ini-файлов
Предыдущий список настроек не является константой. Для плагинов (и файлов conftest.py) возможно добавить опции файла ini. Добавленные опции также будут добавлены в вывод команды pytest --help.
Теперь давайте рассмотрим некоторые изменения конфигурации, которые мы можем внести с помощью встроенных настроек INI-файла, доступных в core pytest.
src расположение
Хотя этот подход можно использовать с компоновкой src (поместите conftest.py в conftest.py src ):
PYTHONPATH в виду, что добавление src в PYTHONPATH уменьшает значение и преимущества макета src ! Вы закончите тестированием кода из репозитория, а не установленного пакета. Если вам нужно сделать это, возможно, вам вообще не нужен src dir.
Встроенные параметры конфигурационного файла¶
Полный лист возможных настроек конфигурационного файла см. reference documentation .
Руководство по использованию метки pytest отсутствует.
- Конкурсные 0
- Неотвеченные
- Цитируемые
- Рейтинг
- Неотвеченные (мои метки)
объяснение
pytest ищет модули conftest в conftest тестов для сбора пользовательских хуков и фикстур, а для импорта из них пользовательских объектов pytest добавляет родительский каталог conftest.py в sys.path .
Остановка pytest от поиска в неправильных местах
Знаете ли вы, что одно из определений «recurse» заключается в том, что бы дважды выругаться в собственом коде? Ну, нет. На самом деле, это означает учет подкаталогов. pytest включит обнаружение тестов рекурсивно исследуя кучу каталогов. Но есть некоторые каталоги, которые вы хотите исключить из просмотра pytest.
Значением по умолчанию для norecurse является '. * Build dist CVS _darcs and *.egg. Having '.*' — это хорошая причина назвать вашу виртуальную среду '.venv', потому что все каталоги, начинающиеся с точки, не будут видны.
В случае проекта Tasks, не помешает указать src , потому что поиск в тестовых файлах с помощью pytest будет пустой тратой времени.
При переопределении параметра, который уже имеет полезное значение, такого как этот параметр, полезно знать, какие есть значения по умолчанию, и вернуть те, которые вам нужны, как я делал в предыдущем коде с *.egg dist build .
norecursedirs — своего рода следствие для тестовых путей, поэтому давайте посмотрим на это позже.
Динамическое добавлений опций командной строки¶
С помощью Опции конфигурации можно статически добавить опцию командной строки для вашего проекта. Можно также динамически модифицировать аргументы командной строки перед их обработкой:
Если у вас установлен xdist plugin, то теперь вы будете всегда прогонять тесты с использованием числа подпроцессов, близкого к параметрам вашего процессора. Запустим в пустой директории с нашим conftest.py :
Байт строки pytest
Отображается байт строки вместо русских слов \u0410\u043f\u043f\u0430\u0440\u0430\u0442 в @pytest.mark.parametrize при считывание из текстового файла. В файле кодировка utf-8 указана.
Тестирование по шагам (incremental testing)¶
Иногда тесты могут состоять из нескольких серий, и выполнять их надо по шагам. Если на каком-то шаге тест упал, нет смысла выполнять следующие шаги этой серии, поскольку они в любом случае должны упасть и трейсбэк не пополнится никакой полезной информацией. Ниже - пример файла conftest.py , который вводдит маркер incremental для использования с классами:
Эти два хука совместно работают на прерывание маркированных incremental тестов в классе. Вот пример тестового модуля:
Посокольку test_modification упал, test_deletion не выполнялся и попал в отчет как «ожидаемо падающий» (xfailed).
Что дальше
В то время как pytest является чрезвычайно мощным сам по себе—особенно с плагинами—он также хорошо интегрируется с другими инструментами разработки программного обеспечения и тестирования программного обеспечения. В следующей главе мы рассмотрим использование pytest в сочетании с другими мощными инструментами тестирования.
Изменение параметров командной строки по умолчанию
Вы использовали уже некоторые параметры командной строки для pytest, таких как -v/--verbose для подробного вывода -l/--showlocals для просмотра локальных переменных с трассировкой стека для неудачных тестов. Вы можете обнаружить, что всегда используете некоторые из этих options—or и предпочитаете использовать them—for a project . Если вы устанавливаете addopts в pytest.ini для нужных вам параметров, то вам больше не придется вводить их. Вот набор, который мне нравится:
Зарегистрировав эти маркеры, вы теперь также можете увидеть их с помощью pytest --markers с их описаниями:
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):
List the Valid ini-file Options with pytest –help
Вы можете получить список всех допустимых параметров для pytest.ini из pytest --help :
Вы увидите все эти настройки в этой главе, за исключением doctest_optionflags , который рассматривается в главе 7, "Использование pytest с другими инструментами", на странице 125.
python_files
Как и pytest_classes , python_files изменяет правило обнаружения тестов по умолчанию, которое заключается в поиске файлов, начинающихся с test_* или имеющих в конце *_test .
Допустим, у вас есть пользовательский тестовый фреймворк, в котором вы назвали все свои тестовые файлы check_.py . Кажется разумным. Вместо того, чтобы переименовывать все ваши файлы, просто добавьте строку в pytest.ini следующим образом:
Очень просто. Теперь вы можете постепенно перенести соглашение об именах, если хотите, или просто оставить его как check_* .
Добавление информации к заголовку отчета¶
Добавить дополнительную информацию к запуску pytest легко:
При выводе эта строка отобразится в заголовке:
Можно возвращать список строк - для каждого элемента списка будет добавлена отдельная строка. Можно также рассмотреть config.getoption('verbose') для получения подробной информации:
Эта строка будет добавлена только при использовании опции --v :
А без этой опции вывод не изменится:
Алгоритм нахождения rootdir ¶
Вот алгоритм поиска корневого каталога из args :
определяем общий родительский каталог для переданных аргументов, которые распознаны в качестве существующих путей файловой системы. Если таких аргументов-путей нет, то текущей рабочей директорией становится общий родительский каталог;
ищем файлы pytest.ini , tox.ini и setup.cfg в каталоге-предке и выше. Если находим - он становится ini-файлом, а его каталог становится rootdir .
если ini-файлы не найдены, для определения rootdir ищем файл setup.py вверх от общего каталога-предка.
если файл setup.py не найден, ищем файлы pytest.ini , tox.ini и setup.cfg в каждом указанном аргументе args и выше. Если нашли - он становится ini-файлом, а его директория становится корневой.
если вообще никаких ini-файлов не найдено, то в качестве rootdir используется уже определенный общий каталог-предок. Это позволяет использовать pytest в стуктурах, которые не являются частью пакета и не имеют никакой конкретной конфигурации.
Если никакие args не указаны, pytest начинает определение rootdir из текущего рабочего каталога и оттуда же собирает тесты.
В настраиваемых плагинах pytest аргументы командной строки могут включать путь, как в pytest --log-output ../../test.log args . В этом случае передавать args обязательно, в противном случае pytest использует для определения корневой директории папку test.log (также см. issue 1435). Для ссылки на текущий рабочий каталог можно использовать точку "." .
Обратите внимание, что существующий файл pytest.ini всегда будет считаться ini-файлом, тогда как tox.ini и setup.cfg файлы должны содержать секции [pytest] или [tool:pytest] соответственно. Опции из разных кандидатов в ini-файлы никогда не сливаются - побеждает первый найденный (при этом pytest.ini побеждает всегда, даже если в нем нет секции [pytest] ).
Затем объект config приобретает следующие атрибуты:
config.rootdir : определенная корневая директория, гарантированно существует.
config.inifile : определенный ini-файл, может быть и None .
rootdir используется для генерации идентификаторов узлов тестов («nodeids»). Ее также могут использовать плагины для хранения установочной информации.
здесь определяется общий предок path и потом ini-файлы ищутся следующим образом:
Как изменить опции командной строки по умолчанию¶
Печатать одни и те жа параметры командной строки каждый раз при запуске pytest может быть утомительно. К примеру, вы всегда хотели бы видеть подробную информацию и пропущенных и «xfail» тестах и лаконичную «точку» для прошедших. Тогда вы можете написать в конфигурационном файле:
Кроме того, можно установить переменную окружения PYTEST_ADDOPTS , чтобы добавить параметры командной строки для использования в этой среде:
Вот как конструируется командная строка при наличии addopts или переменных окружения:
Так что если пользователь напишет в командной строке:
фактически будет выполнена команда:
Обратите внимание, что как и в других интерпретируемых приложениях, если параметры конфликтуют друг с другом - применяется последний. Поэтому в примере выше будет показан подробный вывод, поскольку опция -v перезапишет опцию -q .
Не могу написать тест на создание поста. (DRF)
У меня есть тест на get запрос о списке всех постов, он прекрасно работает. Но я не могу сделать post запрос на создание тех самых постов. По началу была проблема в том что я не мог авторизоваться, но .
Pytest+FastAPI+SQLAlchemy+Postgres: ошибка InterfaceError
Разрабатывая апп на FastAPI, SQLAlchemy и PostgreSQL встретил ошибки при организации тестирования (однако с SQLite всё работает). Сделал репо с минимальной версией аппа и тестированием через Pytest на .
«Заморозка» pytest ¶
Если вы «замораживаете» приложение с помощью инструмента вроде PyInstaller, чтобы распространить его среди конечных пользователей, хорошей идеей будет упаковать и ваш pytest и запускать тесты с «замороженным» приложением. Благодаря такому способу некоторые ошибки (например, отсутствие в исполняемом файле нужных зависимостей) могут быть обнаружены на раннем этапе; кроме того, это позволяет вам отправлять тестовые файлы пользователям, чтобы они сами могли запустить тесты на своих машинах, что может быть полезно для получения дополнительной информации о трудновоспроизводимой ошибке.
К счастью, в последних релизах PyInstaller уже есть хук для pytest , но если вы используете для «заморозки» другие инструменты, такие как cx_freeze или py2exe , можно использовать pytest.freeze_includes() для получения полного списка используемых pytest модулей. Однако конфигурирование инструмента для поиска внутренних модулей зависит от используемого инструмента.
Вместо того, чтобы «заморозить» pytest как отдельный исполняемый файл, можно заставить «замороженную» программу воспринимать pytest как некий хитрый аргумент, к которому она обращается во время запуска. Это позволит вам иметь один исполняемый файл - обычно так удобнее. Обратите внимание, что механизм поиска плагинов, используемый pytest , не работает с «замороженными» исполняемыми файлами, поэтому pytest не сможет найти сторонний плагин автоматически. Чтобы подключить стороние плагины вроде pytest-timeout , их нужно явно импортировать и передать в pytest.main .
Такой шаблон позволит вам запускать тесты на «замороженном» приложении со стандартными опциями командной строки pytest :
Передача значений тестовой функции с помощью опций командной строки¶
Предположим, что мы хотим написать тест, который зависит от опции командной строки. Вот как это делается:
Чтобы это работало, нам нужно добавить опцию командной строки и представить cmdopt через фикстуру :
Давайте запустим БЕЗ нашей новой опции:
А теперь применим cmdopt :
Как видите, значение опции появилось в нашем тесте. Это основной шаблон. Однако скорее всего захочется обрабатывать опцию вне тестов, а так же передавать ее различным или более сложным объектам.
python_functions
python_functions действует как две предыдущие настройки, но для тестовых функций и имен методов. Значение по умолчанию — test_* . А чтобы добавить check_* —вы угадали—сделайте это:
Соглашения об именах pytest не кажутся такими уж ограничивающими, не так ли? Так что, если вам не нравится соглашение об именах по умолчанию, просто измените его. Тем не менее, я призываю вас иметь более вескую причину для таких решений. Миграция сотен тестовых файлов — определенно веская причина.
Куда пойти отсюда
Конечно, модули conftest – это не просто файлы, помогающие в обнаружении исходного кода; это место, где происходят все специфичные для проекта улучшения платформы pytest и настройка вашего набора тестов. pytest много информации о модулях conftest разбросанных по всем документам; начать с conftest.py : локальные плагины для каждого каталога
Кроме того, у SO есть отличный вопрос по модулям conftest : что такое использование файлов conftest.py в py.test?
Вы можете запускать PYTHONPATH в корне проекта
Или используйте pip install как редактируемый импорт
Запускать pytest как модуль с помощью: python -m pytest tests
Я создал это как ответ на ваш вопрос и свое собственное замешательство. Я надеюсь, что это помогает. Обратите внимание на PYTHONPATH как в командной строке py.test, так и в tox.ini.
В частности: вы должны указать py.test и tox, где вы найдете модули, которые вы включаете.
С помощью py.test вы можете сделать это:
И с помощью токсичности добавьте это в ваш tox.ini:
Я получал эту ошибку из-за чего-то еще более простого (можно даже сказать тривиально). Я не установил модуль pytest . Поэтому простой apt install python-pytest исправил это для меня.
‘pytest’ был бы указан в setup.py как тестовая зависимость. Убедитесь, что вы также установили требования к тестированию.
Я исправил это, удалив верхний уровень __init__.py в родительской папке моих источников.
Для меня проблема была tests.py сгенерированная Django вместе с каталогом tests . Снятие tests.py решило проблему.
Я получил эту ошибку, так как неправильно использовал относительный импорт. В примере OP test_app.py должен импортировать функции, используя, например,
Однако в общем случае файлы __init__.py разбросаны по файловой структуре, это не работает и создает вид импортируемой ошибки, если только файлы и тестовые файлы не находятся в одном каталоге.
Вот пример того, что я должен был сделать с одним из моих проектов:
Вот моя структура проекта:
Чтобы получить доступ к activity_indicator.py из test_activity_indicator.py, мне нужно было:
- запустите test_activity_indicatory.py с правильным относительным импортом:
- поместите файлы __init__.py по всей структуре проекта:
У меня была похожая проблема. pytest не распознал модуль, установленный в среде, в которой я работал.
Я решил это, также установив pytest в той же среде.
Очень часто тесты прерывались из-за невозможности импорта модуля. После исследования я обнаружил, что система ищет файл в неправильном месте, и мы легко можем решить проблему, скопировав файл, содержащий модуль, в та же папка, как указано, для правильного импорта. Еще одно решение – изменить объявление для импорта и показать MutPy правильный путь к блоку. Однако из-за того, что несколько модулей могут иметь эту зависимость, а это означает, что нам необходимо зафиксировать изменения и в их объявлениях, мы предпочитаем просто переместить модуль в папку.
Вернуться Дальше
В этой главе мы рассмотрим файлы конфигурации, которые влияют на pytest, обсудим, как pytest изменяет свое поведение на их основе, и внесем некоторые изменения в файлы конфигурации проекта Tasks.
Примеры в этой книге написаны с использованием Python 3.6 и pytest 3.2. pytest 3.2 поддерживает Python 2.6, 2.7 и Python 3.3+.
Под спойлером приведен список статей этой серии.
Необходимо передать параметризированную фикстуру в другой файл в pytest
У меня есть conftest файл в котором создана фикстура, которая должна передавать несколько параметров за раз в ходе прогона тестов. Я использую паттерн page object model. У меня есть отдельный файл (.
Обработка отчетов¶
Если нужно обрабатывать отчеты pytest или получать доступ к исполняющему тесты окружению, можно реализовать хук, который будет вызываться во время создания объекта «report». Ниже мы обрабатываем все упавшие тесты и получаем доступ к фикстуре (если она используется в тестах), которую хотим посмотреть во время обработки. Всю информацию мы запишем в файл failures :
Допустим, у нас есть тесты:
Мы получили файл failures с идентификаторами упавших тестов:
спецификация дерева тестового каталога
В то время как norecursedirs указывает pytest куда не надо заглядыывать, testpaths говорит pytest, где искать. testspaths — это список каталогов относительно корневого каталога для поиска тестов. Он используется только в том случае, если в качестве аргумента не указан каталог, файл или nodeid .
Предположим, что для проекта Tasks мы поместили pytest.ini в каталог tasks_proj вместо тестов:
Тогда может иметь смысл поместить тесты в testpaths :
Теперь, если вы запускаете pytest из каталога tasks_proj , pytest будет искать только в tasks_proj/tests . Проблема здесь в том, что во время разработки и отладки тестов я часто перебираю тестовый каталог, поэтому я могу легко тестировать подкаталог или файл, не указывая весь путь. Поэтому мне этот параметр мало помогает в интерактивном тестировании.
Тем не менее, он отлично подходит для тестов, запускаемых с сервера непрерывной интеграции или с tox-а. В этих случаях вы знаете, что корневой каталог будет фиксированным, и вы можете перечислить каталоги относительно этого фиксированного корневого каталога. Это также те случаи, когда вы действительно хотите сократить время тестирования, так что избавиться от поиска тестов — это здорово.
На первый взгляд может показаться глупым использовать одновременно и тестовые пути, и norecursedirs . Однако, как вы уже видели, тестовые пути мало помогают в интерактивном тестировании из разных частей файловой системы. В этих случаях norecursedirs могут помочь. Кроме того, если у вас есть каталоги с тестами, которые не содержат тестов, вы можете использовать norecursedirs , чтобы избежать их. Но на самом деле, какой смысл ставить дополнительные каталоги в тесты, которые не имеют тестов?
Инициализация: определение корневой директории и файла инициализации¶
pytest определяет корневую директорию rootdir при каждом прогоне тестов в зависимости от параметров командной строки (уточняющих пути и файлы) и существования инициализирующих файлов (ini-files). Определенные таким образом rootdir и ini-file печатаются в заголовочной части при запуске pytest .
Для чего pytest использует rootdir :
Для генерации идентификаторов узлов во время сборки тестов; каждому тесту сопоставляется уникальный nodeid относительно rootdir , который учитывает полный путь, имена класса и функции, а также значение параметризации (если есть).
Используется плагинами для хранения специфичной для проекта/запуска тестов информации; к примеру, внутренний плагин cache создает в rootdir поддиректорию .pytest_cache для хранения состояний выполнения тестов.
rootdir НЕ используется для модификации sys.path / PYTHONPATH и не оказывает влияния на импорт модулей. Подробнее см. sys.path/PYTHONPATH и механизм импорта pytest .
Опцию командной строки --rootdir=path указывают для принудительной установки определенного каталога. Передаваемый каталог может включать переменные окружения, если используется совместно с addopts из файла pytest.ini .
Selenium grid. параллельный запуск тестов в python
Сейчас я использую такую конструкцию для запуска тестов. Я передаю в команднйо строке имя браузера и количество потоков припомощи pytest-xdist def __init__(self, browser): desired_capabilites = .
Использование logging в pytest
Я понимаю, что вопрос описан неоднократно, и как использовать logger для простых функций/ методов мне ясно, но как использовать logger именно с pytes я никак не могу понять. Я потратил несколько часов .
Установил selenium. Дальше вот этого дело не двинулось. как посмотреть приходит ли что то вообще по запросу? как узнать структуру JSON если он приходит. Это первая попытка UI тестирования. не корите .
Конфигурация
До сих пор в этой книге я говорил о различных нетестовых файлах, которые влияют на pytest в основном мимоходом, за исключением conftest.py, который я довольно подробно рассмотрел в главе 5, Плагины, на странице 95. В этой главе мы рассмотрим файлы конфигурации, которые влияют на pytest, обсудим, как pytest изменяет свое поведение на их основе, и внесем некоторые изменения в файлы конфигурации проекта Tasks.
из pytest никак не обратится к logging
Читайте также: