Pytest для QA Automation: с чего начинать писать автотесты

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

Автотесты помогают превратить ожидаемое поведение приложения в код, который можно запускать снова и снова. Pytest — один из самых распространённых инструментов для таких проверок в Python. Он не тестирует приложение «сам по себе», но даёт удобный способ описывать сценарии, запускать их, видеть результат и постепенно собирать устойчивый набор проверок.

Зачем автоматизатору нужен Pytest

Pytest используют для разных типов проверок. С его помощью можно тестировать отдельную функцию, проверить ответ API, подготовить данные для сценария или управлять браузером через инструмент UI-автоматизации. Общая идея остаётся одинаковой: есть действие, есть ожидаемый результат, и тест должен показать, совпали ли они.

Для QA Automation Pytest удобен тем, что позволяет начать с простых функций и постепенно перейти к более сложным сценариям. Не нужно сначала строить большой тестовый фреймворк. Гораздо полезнее написать несколько понятных проверок, увидеть, как они запускаются, научиться читать сообщения об ошибках и только затем добавлять общие настройки, параметризацию и интеграцию с CI/CD.

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

Какая база Python нужна для первых тестов

Перед Pytest не нужно знать весь Python. Однако полезно уверенно работать с переменными, условиями, функциями, списками, словарями и модулями. Тест — это тоже программа: он получает данные, выполняет действие и сравнивает фактический результат с ожидаемым.

Например, если сервис возвращает JSON-ответ, тест должен уметь прочитать словарь, найти нужное поле и проверить его значение. Если проверяется функция расчёта, важно понимать, какие аргументы ей передать и какой результат должен вернуться. Основы языка можно освежить в статьях «Что такое Python» и «Функции в Python».

На старте не стоит откладывать тесты до момента, когда Python будет изучен «полностью». Намного полезнее осваивать язык через небольшие практические проверки. Так функции, условия и структуры данных перестают быть отдельными темами и сразу получают понятное применение.

Из чего состоит простой тест

У большинства тестов есть три смысловые части. Сначала нужно подготовить данные и окружение. Затем выполнить действие, которое проверяется. В конце — сравнить фактический результат с ожидаемым. Этот подход часто называют arrange, act, assert: подготовить, выполнить, проверить.

В Pytest проверка обычно записывается через обычный assert. Если условие истинно, тест проходит успешно. Если нет, Pytest показывает, какое ожидание не выполнилось. Имена тестов обычно начинаются с test_, чтобы фреймворк мог найти их при запуске.

def test_discount_is_applied():
    price = 1000
    discount = 100

    total = price - discount

    assert total == 900

Пример очень простой, но он показывает главную идею. Тест не просто выполняет арифметику, а фиксирует ожидаемое правило: скидка 100 должна уменьшить цену 1000 до 900. Если после изменения в коде результат станет другим, проверка сразу сообщит об этом.

В реальном проекте вместо такой формулы может быть функция расчёта заказа, ответ API или сценарий оформления подписки. Но тест будет строиться по той же логике: подготовить условия, выполнить действие и проверить важный результат.

Когда появляются фикстуры

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

Фикстуры Pytest помогают вынести общую подготовку в отдельное место. Тест получает готовый объект через аргумент функции и концентрируется на своём сценарии. Это делает код короче и помогает не забыть важную часть подготовки в одном из тестов.

Не нужно начинать с большого набора фикстур. Иногда достаточно одной: например, клиента API или функции, которая создаёт пользователя. Когда тестов станет больше, появится понимание, какие действия действительно повторяются и должны быть вынесены отдельно.

Зачем нужна параметризация

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

import pytest

@pytest.mark.parametrize(
    "price, discount, expected",
    [
        (1000, 100, 900),
        (500, 0, 500)
    ]
)
def test_discount_cases(price, discount, expected):
    assert price - discount == expected

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

Как Pytest связан с API-тестами

API-тесты проверяют серверную часть приложения без участия браузера. Например, можно отправить запрос на создание пользователя, проверить статус ответа, убедиться, что в JSON есть нужные поля, а при неверных данных сервер возвращает понятную ошибку.

Такие проверки обычно быстрее тестов интерфейса и помогают точнее понять, где возникла проблема. Если API вернул неверный ответ, дело, вероятно, в серверной логике или данных. Если API работает правильно, а пользователь всё равно не может завершить сценарий, можно отдельно исследовать интерфейс.

Для работы с API полезно понимать HTTP: методы, статусы, заголовки и JSON. Если эти понятия пока только начинают складываться, прочитай статьи «Что такое HTTP» и «Что такое API». Тогда API-тест будет восприниматься не как набор непонятных проверок, а как контролируемый запрос к серверу.

Как тесты попадают в CI/CD

Сначала тесты обычно запускают локально. Разработчик или автоматизатор вносит изменения и выполняет команду pytest, чтобы проверить результат. Следующий шаг — включить этот запуск в CI/CD, чтобы проверки выполнялись автоматически после отправки кода в репозиторий.

Например, после изменения в GitHub система может установить зависимости, запустить Pytest и показать статус workflow. Если проверка не проходит, команда увидит это до выпуска новой версии приложения. Общую логику такого процесса объясняет статья «Что такое CI/CD простыми словами».

Автоматический запуск не делает тесты хорошими сам по себе. Важно, чтобы они были независимыми, воспроизводимыми и давали понятное сообщение при падении. Если тест иногда проходит, а иногда нет без изменений в коде, его нужно исследовать и исправить. Нестабильная проверка снижает доверие ко всему набору тестов.

Как двигаться дальше

После первых проверок логики можно перейти к небольшим API-тестам: проверить успешный ответ, неверные входные данные, отсутствие прав доступа и другие важные сценарии. Затем появятся фикстуры для общих действий, параметризация для повторяющихся случаев и более удобная структура проекта.

Автоматизацию пользовательского интерфейса с Selenium или Playwright лучше добавлять после того, как ты уверенно пишешь тесты на Python и понимаешь работу API. Интерфейсные проверки часто требуют больше настройки и могут быть чувствительны к изменениям страницы. База из логических и API-тестов помогает перейти к ним без лишней сложности.

В треке QA Automation Engineer на TeoBrain Pytest рассматривается как часть последовательного пути: от основ Python и тест-дизайна к API-тестированию, UI-автоматизации, CI/CD и проектной практике. Такой порядок помогает не просто выучить синтаксис проверок, а понять, какую роль они играют в качестве продукта.

Что стоит запомнить

Pytest помогает описывать ожидаемое поведение приложения в виде повторяемых проверок. Начинать полезно с небольших тестов, где легко увидеть связь между действием и ожидаемым результатом. Затем можно добавлять фикстуры, параметризацию, API-тесты и автоматический запуск в CI/CD.

Главное — не количество тестов, а их смысл. Хорошая проверка отвечает на понятный вопрос: какое важное поведение приложения она защищает? Если ты хочешь постепенно освоить этот подход на практике, посмотри программу трека QA Automation Engineer на TeoBrain и выбери следующий связанный курс.