Comments 22
Добавлю к статье - откуда брать данные для тестирования. Можно, конечно, самим придумать, но есть сторонние библиотеки faker и mimesis. Я бы рекомендовал mimesis - там отличная документация и тестовые данные на любой вкус и цвет: будь то картинки, номера телефонов, IP-адреса и почти все что только можно
Я стараюсь тестовые данные писать сам. Тесты == документация к использованию моего приложения. Часто можно показать пользователю(другому разработчику) более реальные пути использования приложения в добавок к покрытию тестами.
В любом случае ваш совет имеет место быть и может многим показать как упросить себе жизнь, спасибо!
Рандомная генерация данных позволяет отловить больше потенциальных ошибок, чем когда эти данные создаются вручную, вручную данные получаются чаще ближе к идеальным условиям и тесты с ними c большей вероятностью будут пропускать уязвимости.
Возможно, у вас есть причины использовать такой подход по умолчанию.
Вам это помогало в юнит-тестах или интеграционных? Есть наглядный пример(ы), где вы нашли баг из-за рандомизации тестовых данных ?
Да, такие ситуации случались, но я, увы, не веду по ним записи. Чаще всего это приводит к flaky(моргающим) тестам.
Думаю тут нужно разбирать конкретный кейс.
Обычно, faker приносит пользу разработчикам для юнит-тестов.
Тестировщики же, как правило, и так отлично понимают какие в рамках теста корнер-кейсы и что нужно подать на вход теста. Применяют всяке техники, например Pair Wise Testing, Border Values Analysis, Equivalence Classes, etc. Я тут больще за всякие утилиты вроде PICT для помощи с Pair Wise.
Потому как если просто отдать на откуп faker, то колличество тестов начинает расти неадекватной прогрессией. И на действительно нужные тестовые данные, будет приходиться 100 за компанию. А ведь каждый набор данных - это лишний тест ран, т.е. время. Регулярная практика на больших проектах вычищать бесполезные тесты, которые накидали на всякий случай. Иногда, проще вообще выкинуть такие фреймворки, чем разбирать что там такого насочиняли и почему тест-ран занимает 2-3 дня.
А зачем объединять тесты в классы? Кроме лишнего отступа это ничего не даёт.
В питоне, если нет внутреннего состояния - нет смысла объединять группу функций в объект с методами
Тестовый класс объединяет в себе тесты тестируемого класса(тесты связаны одной целью).
Есть примеры, когда нет состояния, но есть класс. Например, при применении паттерна абстрактная фабрика. Или обычная фабрика, которая умеет из разных входных данных создавать или разные виды объекта. Не единственные примеры. Первое, что пришло в голову.
Искать очень удобно, когда тестовый класс называется точно так же, как класс, который он тестирует с припиской тест.
Декораторы от 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)