Сначала зафиксируйте правило
Пусть условия вымышленного магазина таковы: для суммы заказа от 3000 рублей доставка бесплатна, ниже этой суммы стоит 200 рублей. Функция принимает сумму в целых рублях и возвращает стоимость доставки. Отрицательное значение по договорённости должно вызывать ValueError. Это учебный контракт, а не сведения о реальном магазине. До написания тестов стоит уточнить спорные случаи: допускается ли нулевой заказ, как обрабатываются копейки и какие типы данных разрешены. Если ответ неизвестен, тест не должен незаметно превращать личное предположение разработчика в требование.
Три соседних значения раскрывают границу
Для согласованного правила полезны суммы 2999, 3000 и 3001. Ожидаемая стоимость доставки соответственно равна 200, 0 и 0. Средний случай особенно важен: замена сравнения «больше или равно» на «больше» оставит многие обычные примеры правильными, но изменит результат на самой границе. Проверка только суммы 5000 такую ошибку не обнаружит. При этом три примера не доказывают корректность всех возможных входов. Они отвечают на конкретный вопрос о переходе между двумя режимами. Отрицательное значение проверяют отдельно, поскольку ожидается исключение, а не обычное число.
Ожидание должно иметь независимое основание
Плохой тест заново вычисляет ожидаемую доставку тем же условием, которое написано в проверяемой функции. Если одна и та же ошибка попала в обе записи, сравнение успешно пройдёт. Надёжнее для выбранных примеров явно указать ответы, полученные из согласованного правила. В pytest параметризация позволяет передать набор пар «сумма заказа, ожидаемая доставка» в одну проверочную функцию. Каждый набор становится отдельным случаем запуска, поэтому по отчёту легче увидеть, какое условие нарушено. Осмысленные названия случаев, например «точно на пороге», делают результат понятнее, чем длинная цепочка неразличимых чисел.
Управляйте условиями и смыслом сбоя
Для простой функции расчёта не нужны сеть, настоящее оформление заказа или платёжная система. Чем меньше внешних условий, тем легче понять причину неудачи. Если проверка использует изменяемые данные, их следует подготавливать так, чтобы один тест не зависел от следов другого. Фикстуры pytest помогают организовать подготовку и освобождение необходимых ресурсов, но не заменяют продуманные ожидания. После сбоя важно прочитать фактическое и ожидаемое значения, проверить исходное правило и лишь затем менять реализацию. Автоматическое переписывание ожидаемого ответа под полученный результат уничтожает смысл проверки. Успешный запуск сообщает о пройденных сценариях, а не об отсутствии любых ошибок в программе.
Попробуйте на практике
Составьте набор проверок учебной доставки без установки программ.
- Перепишите правило бесплатной доставки так, чтобы было ясно, включается ли сумма 3000 рублей.
- Сделайте три строки для 2999, 3000 и 3001 рубля и впишите ожидаемые ответы независимо от кода.
- Добавьте отдельный случай отрицательной суммы с ожидаемым ValueError.
- Представьте ошибочную реализацию, которая делает доставку бесплатной только при сумме строго больше 3000, и отметьте обнаруживающий её случай.
- Дайте каждому случаю короткое название, объясняющее его назначение.
Как проверить результат. В таблице указаны ответы 200, 0 и 0; ошибка строгого сравнения обнаруживается на 3000. Проверка отрицательного входа ожидает исключение, а не придуманную стоимость.
Частые вопросы
Чем больше тестовых чисел, тем лучше проверка?
Количество само по себе мало говорит о качестве. Нужны случаи, проверяющие разные условия, границы и согласованные ошибки входа.
Нужна ли фикстура для каждой проверки?
Нет. Она полезна для осмысленной подготовки данных или ресурсов. Простой расчёт с явными аргументами может обходиться без отдельной фикстуры.
Самостоятельный разбор темы. Содержание конкретной обучающей программы здесь не представлено.