Comments 21
Добавлю к статье - откуда брать данные для тестирования. Можно, конечно, самим придумать, но есть сторонние библиотеки faker и mimesis. Я бы рекомендовал mimesis - там отличная документация и тестовые данные на любой вкус и цвет: будь то картинки, номера телефонов, IP-адреса и почти все что только можно
Я стараюсь тестовые данные писать сам. Тесты == документация к использованию моего приложения. Часто можно показать пользователю(другому разработчику) более реальные пути использования приложения в добавок к покрытию тестами.
В любом случае ваш совет имеет место быть и может многим показать как упросить себе жизнь, спасибо!
Рандомная генерация данных позволяет отловить больше потенциальных ошибок, чем когда эти данные создаются вручную, вручную данные получаются чаще ближе к идеальным условиям и тесты с ними c большей вероятностью будут пропускать уязвимости.
А зачем объединять тесты в классы? Кроме лишнего отступа это ничего не даёт.
В питоне, если нет внутреннего состояния - нет смысла объединять группу функций в объект с методами
Тестовый класс объединяет в себе тесты тестируемого класса(тесты связаны одной целью).
Есть примеры, когда нет состояния, но есть класс. Например, при применении паттерна абстрактная фабрика. Или обычная фабрика, которая умеет из разных входных данных создавать или разные виды объекта. Не единственные примеры. Первое, что пришло в голову.
Искать очень удобно, когда тестовый класс называется точно так же, как класс, который он тестирует с припиской тест.
Декораторы от pytest можно навесить на класс и они применяться к каждому тесту внутри класса, что позволит не весить его на каждый метод.
Также фикстуры можно создавать единожды на класс.
Думаю, если подумать, и/или погуглить можно ещё найти причин каких-то.
Делать без класса не плохо. Тут скорее мне нравится объединять в классы тесты.
Обзор фикстур без 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)Планируете рассказать про вcтроенные фикстуры, raises, approx и monkeypatch vs unittest.mock.patch?
Про raises упомянул в самом конце статьи.
Насчёт approx - постараюсь не забыть и упомянуть.
Насчёт последнего - сравнивать не планировал библиотеки в рамках этой серии статей, но рассказывать про возможности патчинга и создания тестовых дублёров планирую.
Причин не помню, но сам обычно использую pytest-mock библиотеку для этих вещей, ну или пишу тестовые дублёры сам.
Про raises упомянул в самом конце статьи.
Насчёт approx - постараюсь не забыть и упомянуть.
Насчёт последнего - сравнивать не планировал библиотеки в рамках этой серии статей, но рассказывать про возможности патчинга и создания тестовых дублёров планирую.
Причин не помню, но сам обычно использую pytest-mock библиотеку для этих вещей, ну или пишу тестовые дублёры сам.
Я бы еще про линтеры упомянул.
- ruff https://docs.astral.sh/ruff/rules/#flake8-pytest-style-pt
- плагин для flake8 https://pypi.org/project/flake8-pytest-style/
Хорошая статья, но кажется зачем, если есть уже Python Testing с pytest? Было бы здорово больше практического опыта..
в фикстуру передать данные можно и третьим способом: она может возвращать вызываемой объект в который в тесте можно будет передать аргументы..
Python — тестирование с помощью pytest(ч.1)