Python — тестирование с помощью pytest(ч.1)

[IvanZaycev0717]

Добавлю к статье - откуда брать данные для тестирования. Можно, конечно, самим придумать, но есть сторонние библиотеки faker и mimesis. Я бы рекомендовал mimesis - там отличная документация и тестовые данные на любой вкус и цвет: будь то картинки, номера телефонов, IP-адреса и почти все что только можно

[KarmanovichDev]

Я стараюсь тестовые данные писать сам. Тесты == документация к использованию моего приложения. Часто можно показать пользователю(другому разработчику) более реальные пути использования приложения в добавок к покрытию тестами.

В любом случае ваш совет имеет место быть и может многим показать как упросить себе жизнь, спасибо!

[a-baskakov]

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

[KarmanovichDev]

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

Вам это помогало в юнит-тестах или интеграционных? Есть наглядный пример(ы), где вы нашли баг из-за рандомизации тестовых данных ?

[a-baskakov]

Да, такие ситуации случались, но я, увы, не веду по ним записи. Чаще всего это приводит к flaky(моргающим) тестам.

[Gadd]

А зачем объединять тесты в классы? Кроме лишнего отступа это ничего не даёт.
В питоне, если нет внутреннего состояния - нет смысла объединять группу функций в объект с методами

[KarmanovichDev]

Тестовый класс объединяет в себе тесты тестируемого класса(тесты связаны одной целью).

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

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

Декораторы от pytest можно навесить на класс и они применяться к каждому тесту внутри класса, что позволит не весить его на каждый метод.

Также фикстуры можно создавать единожды на класс.

Думаю, если подумать, и/или погуглить можно ещё найти причин каких-то.

[KarmanovichDev]

Делать без класса не плохо. Тут скорее мне нравится объединять в классы тесты.

[Gadd]

В качестве контейнера для тестов может служить не только класс, но и модуль. Но ладно, это уже вкусовщина, у каждого свои фломастеры :-)

[Andrey_Solomatin]

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

[Andrey_Solomatin]

Обзор фикстур без yield не будет полным. Очень удобно подчищать за собой. https://docs.pytest.org/en/6.2.x/fixture.html#yield-fixtures-recommended

@pytest.fixture
def sending_user(mail_admin):
    user = mail_admin.create_user()
    yield user
    mail_admin.delete_user(user)

[KarmanovichDev]

Решил что для первой части будет достаточно )

[Andrey_Solomatin]

Планируете рассказать про вcтроенные фикстуры, raises, approx и monkeypatch vs unittest.mock.patch?

[KarmanovichDev]

Про raises упомянул в самом конце статьи.

Насчёт approx - постараюсь не забыть и упомянуть.

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

Причин не помню, но сам обычно использую pytest-mock библиотеку для этих вещей, ну или пишу тестовые дублёры сам.

[Andrey_Solomatin]

Как я понимаю monkeypatch появился намого раньше mock.patch. Сейчас я до конца не определился, что именно использовать и использую их в перемешку.

[KarmanovichDev]

Про raises упомянул в самом конце статьи.

Насчёт approx - постараюсь не забыть и упомянуть.

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

Причин не помню, но сам обычно использую pytest-mock библиотеку для этих вещей, ну или пишу тестовые дублёры сам.

[Andrey_Solomatin]

Я бы еще про линтеры упомянул.

- ruff https://docs.astral.sh/ruff/rules/#flake8-pytest-style-pt
- плагин для flake8 https://pypi.org/project/flake8-pytest-style/

[KarmanovichDev]

Кажется, что код-стайл это дело каждого(каждой команды). Особенно когда он выходит за рамки стандартных линтеров и является доп. библиотеками.

[Exinker]

Хорошая статья, но кажется зачем, если есть уже Python Testing с pytest? Было бы здорово больше практического опыта..

в фикстуру передать данные можно и третьим способом: она может возвращать вызываемой объект в который в тесте можно будет передать аргументы..

[KarmanovichDev]

Это лишь первая часть) В следующих частях будут углубления в тему.

Учту третий пример на будущее, спасибо.

Получается, если где-то есть первоисточник, или другая статья, то лучше не стоит писать свои мысли и опыт ?)

[Exinker]

Почему? опыт как раз и интересен.