Автоматизированное тестирование на Python: Путь от Junior до Senior

Основы тестирования: пирамида, жизненный цикл и виды тестов

Добро пожаловать на курс «Автоматизированное тестирование на Python: Путь от Junior до Senior». Мы начинаем с фундамента. Прежде чем писать код на pytest или разворачивать Docker-контейнеры, необходимо разобраться в архитектуре качества. Без понимания того, что и зачем мы тестируем, даже самый сложный код будет бесполезен.

В этом модуле мы разберем теорию, которая отличает инженера по автоматизации от простого «писателя скриптов», и напишем первые тесты на чистом Python.

Цель модуля

К концу этого занятия вы будете:

Понимать концепцию Пирамиды тестирования и избегать антипаттернов.
Знать этапы Жизненного цикла тестирования (STLC).
Различать виды тестов: Unit, Integration, E2E, Smoke, Regression.
Уметь применять паттерн AAA (Arrange-Act-Assert) на практике.

Теория

1. Пирамида тестирования (Testing Pyramid)

Это ключевая ментальная модель для QA-инженера. Она определяет стратегию автоматизации: сколько и каких тестов нужно писать.

Уровни пирамиды (снизу вверх):

Unit Tests (Модульные тесты)
- Суть: Проверка наименьшей единицы кода (функции, метода) в полной изоляции. Никаких баз данных, сети или файловой системы.
- Скорость: Мгновенная (миллисекунды).
- Количество: 70-80% от всех тестов.
- Инструменты: unittest, pytest.
Integration Tests (Интеграционные тесты)
- Суть: Проверка взаимодействия между компонентами (например, сервис + база данных, или сервис A + сервис B).
- Скорость: Средняя (секунды).
- Количество: 15-20%.
- Инструменты: pytest, requests, Docker.
E2E / UI Tests (Сквозные тесты)
- Суть: Эмуляция действий реального пользователя через интерфейс. Проверяем систему целиком.
- Скорость: Медленная (минуты).
- Количество: 5-10% (только критические сценарии).
- Инструменты: Selenium, Playwright.

Антипаттерн «Рожок мороженого» (Ice Cream Cone): Ситуация, когда проект перегружен медленными UI-тестами при отсутствии Unit-тестов. Это ведет к нестабильности (flaky tests) и долгому ожиданию результатов.

2. Жизненный цикл тестирования (STLC)

Автоматизация не существует в вакууме. Она встраивается в процесс STLC (Software Testing Life Cycle):

Requirement Analysis: Понимаем, что тестировать. Если требование нелогично, писать автотест рано.
Test Planning: Выбираем инструменты (Python + pytest) и стратегию.
Test Case Design: Пишем сценарии. Важно: хороший автотест рождается из хорошего ручного тест-кейса.
Environment Setup: Настройка тестовой среды (БД, тестовые данные).
Execution: Запуск тестов (CI/CD).
Closure: Анализ отчетов и покрытия кода.

3. Виды тестов по цели запуска

Smoke Testing (Дымовое): Быстрая проверка критического функционала («Запускается ли приложение?», «Работает ли логин?»). Если дым идет — глубокое тестирование не имеет смысла.
Regression Testing (Регрессионное): Полный прогон тестов после внесения изменений в код. Гарантия того, что новые фичи не сломали старые. Это главная задача автотестов.

4. Паттерн AAA (Arrange-Act-Assert)

Золотой стандарт структуры теста. Если ваши тесты не следуют этому паттерну, их будет сложно читать и поддерживать.

Arrange (Подготовка): Создаем объекты, настраиваем моки, готовим данные.
Act (Действие): Вызываем тестируемый метод.
Assert (Проверка): Сравниваем фактический результат с ожидаемым.

Полезные ссылки

The Practical Test Pyramid (Martin Fowler) — библия для автоматизатора.
Software Testing Life Cycle — подробнее про этапы.

Практика

В этом модуле мы используем чистый Python и оператор assert, чтобы понять механику проверок без «магии» фреймворков.

Задача 1: Чистая функция (Unit-тест)

Дано: Функция расчета скидки. Задача: Написать тест, проверяющий корректность расчета и валидацию входных данных.

# app.py
def calculate_discount(price, discount_percent):
    if price < 0 or discount_percent < 0:
        raise ValueError("Values must be positive")
    if discount_percent > 100:
        raise ValueError("Discount cannot exceed 100%")
    return price * (1 - discount_percent / 100)

# test_app.py
def test_calculate_discount():
    # 1. Arrange
    price = 1000
    percent = 20
    expected = 800

    # 2. Act
    result = calculate_discount(price, percent)

    # 3. Assert
    assert result == expected, f"Expected {expected}, but got {result}"
    print("Unit-тест пройден!")

test_calculate_discount()

Задача 2: Тестирование состояния (Stateful Testing)

Дано: Класс User, который может менять статус. Задача: Проверить переход состояния.

class User:
    def __init__(self, name, is_active=True):
        self.name = name
        self.is_active = is_active

    def ban(self):
        self.is_active = False

def test_user_ban():
    # Arrange
    user = User("Alex")

    # Pre-assertion (проверяем исходное состояние)
    assert user.is_active is True, "User should be active initially"

    # Act
    user.ban()

    # Assert
    assert user.is_active is False, "User should be banned after ban() call"
    print("Тест состояния пройден!")

test_user_ban()

Задача 3: Ручной Mock (Интеграционный тест)

Дано: Сервис отправки уведомлений, зависящий от внешнего провайдера (Email). Задача: Протестировать логику сервиса, подменив реальную отправку писем «заглушкой» (Mock), чтобы не спамить реальными письмами.

# --- Реальный код ---
class EmailProvider:
    def send(self, message):
        # Представим, что тут сложная логика отправки по сети
        print(f"Sending email: {message}")

class NotificationService:
    def __init__(self, provider):
        self.provider = provider

    def notify_admin(self, error_msg):
        formatted_msg = f"CRITICAL ERROR: {error_msg}"
        self.provider.send(formatted_msg)

# --- Тестовый код ---

# Создаем Mock-объект (имитацию)
class MockEmailProvider:
    def __init__(self):
        self.sent_messages = []

    def send(self, message):
        self.sent_messages.append(message)

def test_notification_service():
    # Arrange
    mock_provider = MockEmailProvider() # Внедряем зависимость
    service = NotificationService(mock_provider)

    # Act
    service.notify_admin("Database down")

    # Assert
    # 1. Проверяем, что метод send был вызван ровно 1 раз
    assert len(mock_provider.sent_messages) == 1, "Email should be sent once"

    # 2. Проверяем, что сообщение отформатировано верно
    expected_msg = "CRITICAL ERROR: Database down"
    actual_msg = mock_provider.sent_messages[0]
    assert actual_msg == expected_msg, f"Wrong message format. Got: {actual_msg}"

    print("Интеграционный тест с моком пройден!")

test_notification_service()

Домашнее задание

Контекст: Вы разрабатываете систему для интернет-магазина. Есть класс Cart (Корзина), который позволяет добавлять товары (словарь {'name': str, 'price': int}), удалять их и считать общую сумму.

Задание:

Реализуйте класс Cart с методами add_item(item), remove_item(item_name), calculate_total().
Напишите 3 теста (функции), используя assert и паттерн AAA:
- Тест добавления товара (проверить, что товар появился в списке и сумма изменилась).
- Тест удаления товара.
- Тест пустой корзины (сумма должна быть 0).
Критерии приемки:
- Код запускается без ошибок.
- При изменении логики calculate_total (например, добавить +1 к сумме) тесты должны падать с ошибкой AssertionError.
- В каждом тесте есть комментарии # Arrange, # Act, # Assert.

Типичные ошибки новичков

«Немые» ассерты:
- Плохо: assert result == 5 (Если упадет, вы увидите просто AssertionError).
- Хорошо: assert result == 5, f"Expected 5, but got {result}" (Сразу понятно, что пошло не так).
Зависимые тесты: Один тест меняет глобальную переменную, а второй падает из-за этого. Каждый тест должен быть изолирован (создавать свои данные заново).
Тестирование всего сразу: Один тест проверяет и логин, и корзину, и оплату. Если он упадет, непонятно, где ошибка. Следуйте правилу: Один тест — одна проверка.

Чек-лист прогресса

[ ] Я понимаю разницу между Unit и E2E тестами.
[ ] Я знаю, что такое AAA и использую его в коде.
[ ] Я написал тест с использованием assert и кастомным сообщением об ошибке.
[ ] Я понимаю, почему нельзя писать только UI-тесты (пирамида).

Погружение в pytest: фикстуры, параметризация и маркировка

В предыдущем модуле мы научились писать простейшие тесты, используя встроенный оператор assert. Это отличный способ понять суть проверок, но в реальных проектах этого недостаточно. Представьте, что у вас 500 тестов. Как запустить только те, что касаются оплаты? Как подготовить базу данных перед каждым тестом и очистить её после? Как проверить одну функцию на 10 разных наборах данных, не копируя код?

Здесь на сцену выходит pytest — самый популярный, мощный и гибкий фреймворк для тестирования в мире Python. Сегодня мы превратим ваши разрозненные скрипты в профессиональный тестовый сьют.

Почему pytest?

Хотя в стандартной библиотеке Python есть модуль unittest (наследие Java JUnit), индустрия сделала выбор в пользу pytest. Причины просты:

Лаконичность: Не нужно создавать классы-наследники от TestCase. Тесты — это просто функции.
Умные ассерты: Не нужно помнить методы self.assertEqual, self.assertTrue. Достаточно простого assert, а pytest сам покажет детальную разницу между ожидаемым и фактическим результатом.
Фикстуры: Революционный подход к управлению зависимостями и состоянием (setup/teardown).
Плагины: Огромная экосистема расширений.

Установка и первый запуск

Для начала установим библиотеку:

pip install pytest

Pytest использует автоматическое обнаружение тестов (test discovery). Чтобы он нашел ваши тесты, соблюдайте правила именования:

Файлы должны называться test_*.py или *_test.py.
Функции тестов должны начинаться с префикса test_.
Классы тестов (если вы их используете) должны начинаться с Test.

Пример файла test_math.py:

def test_addition():
    assert 1 + 1 == 2

def test_subtraction():
    assert 5 - 3 == 2

Запуск из терминала:

pytest

Фикстуры (Fixtures): Сердце pytest

Вспомните паттерн AAA (Arrange-Act-Assert). Этап Arrange (подготовка данных) часто повторяется. Например, для тестирования корзины интернет-магазина нам нужно в каждом тесте создавать экземпляр этой корзины.

Фикстуры — это функции, которые готовят окружение до теста и (опционально) убирают за собой после. Они позволяют отделить код инициализации от логики проверки.

Создание простой фикстуры

Используем декоратор @pytest.fixture.

import pytest
from my_app import Cart  # Предположим, класс Cart у нас есть

@pytest.fixture
def empty_cart():
    print("\n[Setup] Создаем пустую корзину")
    return Cart()

def test_add_item(empty_cart):
    # empty_cart здесь — это уже объект, который вернула фикстура
    empty_cart.add_item("Apple", 10)
    assert empty_cart.total == 10

Обратите внимание на магию: мы передаем имя фикстуры empty_cart как аргумент в функцию теста. Pytest сам найдет фикстуру, выполнит её и передаст результат внутрь теста. Это называется Dependency Injection (Внедрение зависимостей).

Setup и Teardown (Подготовка и Очистка)

Часто нам нужно не только создать ресурс (открыть файл, соединение с БД, браузер), но и закрыть его после теста. Для этого вместо return используется ключевое слово yield.

Всё, что написано до yield, выполняется перед тестом. Всё, что после — после теста (даже если тест упал с ошибкой).

@pytest.fixture
def db_connection():
    # Setup
    conn = connect_to_db("test.db")
    print("Соединение открыто")

    yield conn  # Передаем соединение в тест

    # Teardown
    conn.close()
    print("Соединение закрыто")

Области видимости (Scopes)

По умолчанию фикстура создается заново для каждой функции теста (scope='function'). Но если открытие браузера занимает 5 секунд, а у нас 100 тестов, мы будем ждать вечность. Мы можем изменить время жизни фикстуры.

function: (по умолчанию) один раз для каждого теста.
class: один раз для класса тестов.
module: один раз для всего файла (модуля).
session: один раз за весь запуск тестов (например, глобальная настройка БД).

@pytest.fixture(scope="session")
def global_config():
    return load_config("env.dev")

Файл conftest.py

Если вы хотите использовать фикстуру в нескольких файлах с тестами, не нужно её импортировать. Просто создайте файл conftest.py в корне папки с тестами и поместите фикстуру туда. Pytest увидит её автоматически во всем проекте.

Параметризация: Один тест — много данных

Допустим, нам нужно проверить функцию сложения на разных числах. Новички часто пишут цикл for внутри теста. Это плохая практика: если упадет одна итерация, вы не узнаете результаты остальных, и отчет будет неинформативным.

Используйте декоратор @pytest.mark.parametrize.

# Функция, которую тестируем
def multiply(a, b):
    return a * b

# Тест с параметризацией
@pytest.mark.parametrize("input_a, input_b, expected", [
    (2, 3, 6),
    (0, 5, 0),
    (-1, 5, -5),
    (100, 100, 10000)
])
def test_multiply(input_a, input_b, expected):
    assert multiply(input_a, input_b) == expected

В этом примере pytest сгенерирует и запустит 4 независимых теста. Если упадет кейс с нулем, остальные всё равно выполнятся.

Маркировка (Marks): Управление запуском

Маркеры позволяют помечать тесты тегами, чтобы запускать их выборочно.

Встроенные маркеры

@pytest.mark.skip(reason="Баг еще не исправлен") — пропускает тест.
@pytest.mark.xfail — помечает тест как "ожидаемо падающий". Если он упадет — это не будет считаться ошибкой (зеленый отчет). Если пройдет — будет помечен как XPASS.

Кастомные маркеры

Вы можете придумать свои метки, например smoke, slow, api, ui.

@pytest.mark.smoke
def test_login():
    ...

@pytest.mark.slow
def test_end_to_end_purchase():
    ...

Запуск только smoke-тестов:

pytest -m smoke

Важно: Чтобы pytest не выдавал предупреждения о неизвестных маркерах, их нужно зарегистрировать в файле конфигурации pytest.ini:

[pytest]
markers =
    smoke: критические тесты
    slow: медленные тесты

Проверка исключений

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

Для этого используется контекстный менеджер pytest.raises:

def divide(a, b):
    if b == 0:
        raise ValueError("Cannot divide by zero")
    return a / b

def test_divide_by_zero():
    with pytest.raises(ValueError) as excinfo:
        divide(10, 0)

    # Дополнительная проверка текста ошибки
    assert "Cannot divide by zero" in str(excinfo.value)

Практика

Задача 1: Рефакторинг с фикстурами

У нас есть класс UserManager. Напишите для него тесты, используя фикстуру для создания менеджера перед каждым тестом.

class UserManager:
    def __init__(self):
        self.users = []

    def add_user(self, name, age):
        self.users.append({"name": name, "age": age})

    def get_user_count(self):
        return len(self.users)

Решение:

import pytest

@pytest.fixture
def user_manager():
    return UserManager()

def test_add_user(user_manager):
    user_manager.add_user("Alice", 30)
    assert user_manager.get_user_count() == 1

def test_initial_state(user_manager):
    assert user_manager.get_user_count() == 0

Задача 2: Параметризация валидации пароля

Функция is_valid_password(password) возвращает True, если пароль длиннее 8 символов. Проверьте граничные значения.

Решение:

def is_valid_password(password):
    return len(password) > 8

@pytest.mark.parametrize("password, expected", [
    ("12345678", False),   # Граница (8 символов)
    ("123456789", True),   # Граница + 1
    ("", False),           # Пустая строка
    ("short", False)       # Короткий
])
def test_password_validation(password, expected):
    assert is_valid_password(password) == expected

Домашнее задание

Контекст: Вы продолжаете работать над интернет-магазином. У вас есть класс Product и класс Cart.

class Product:
    def __init__(self, name, price, stock):
        self.name = name
        self.price = price
        self.stock = stock

    def reduce_stock(self, quantity):
        if quantity > self.stock:
            raise ValueError("Not enough stock")
        self.stock -= quantity

Задание:

Создайте файл test_shop.py.
Напишите фикстуру product_iphone, которая возвращает объект Product("iPhone", 1000, 10).
Напишите тест test_reduce_stock_success, который использует фикстуру, уменьшает сток на 5 и проверяет, что осталось 5.
Напишите параметризованный тест test_reduce_stock_failure, который пытается списать больше товара, чем есть (например, 11, 100), и проверяет, что вызывается исключение ValueError.
Добавьте маркер @pytest.mark.critical к тесту успешного списания.

Критерии приемки:

Используется yield не обязательно, но return в фикстуре обязателен.
Параметризация покрывает минимум 2 кейса превышения стока.
Используется pytest.raises.
Тесты запускаются командой pytest -v.

Типичные ошибки

Забыли test_: Функция называется check_login, и pytest её игнорирует.
Мутабельные фикстуры: Если вы используете scope="module" для объекта, который меняется в тестах (например, список), изменения из первого теста повлияют на второй. Для изменяемых объектов используйте scope="function".
Сложная логика в тестах: Если в тесте есть if, for или try-except (кроме pytest.raises), вы, скорее всего, делаете что-то не так. Тест должен быть линейным.

В следующем модуле мы перейдем к тестированию API и научимся отправлять настоящие HTTP-запросы.

API-тестирование: requests, REST, mocking и JSON Schema

Добро пожаловать на третью неделю курса «Автоматизированное тестирование на Python». Мы уже заложили фундамент, разобравшись с пирамидой тестирования, и освоили наш главный инструмент — pytest. Теперь пришло время подняться на ступень выше: от модульных тестов (Unit) к интеграционным, а именно — к тестированию API.

API (Application Programming Interface) — это «клей», который соединяет фронтенд, бэкенд, базы данных и сторонние сервисы. Тестирование API находится в середине пирамиды: эти тесты медленнее юнитов, но гораздо быстрее и стабильнее, чем UI-тесты через браузер. Именно здесь автоматизатор проводит большую часть своего времени.

В этом модуле мы научимся отправлять HTTP-запросы на Python, проверять ответы сервера, валидировать сложные структуры данных и изолировать тесты от внешнего мира.

Цель модуля

К концу этой недели вы будете уметь:

Понимать принципы REST архитектуры и структуру HTTP-запросов.
Использовать библиотеку requests для взаимодействия с API.
Писать автотесты для CRUD-операций (Create, Read, Update, Delete).
Валидировать структуру ответов с помощью JSON Schema.
Применять Mocking для изоляции тестов от реальных сервисов.

Теория: REST и HTTP

Большинство современных веб-сервисов общаются по протоколу HTTP, следуя архитектурному стилю REST (Representational State Transfer). Чтобы тестировать API, нужно понимать, из чего состоит диалог между клиентом (вашим тестом) и сервером.

Анатомия HTTP-запроса

URL (Endpoint): Адрес ресурса, к которому мы обращаемся (например, https://api.shop.com/users/123).
Method (Метод): Глагол, указывающий действие.
- GET — получить данные (безопасный метод, не меняет состояние сервера).
- POST — создать новый ресурс.
- PUT — полностью обновить существующий ресурс.
- PATCH — частично обновить ресурс.
- DELETE — удалить ресурс.
Headers (Заголовки): Метаданные (например, Authorization для токена или Content-Type: application/json).
Body (Тело): Данные, которые мы отправляем (обычно в формате JSON). У GET запросов тела, как правило, нет.

Анатомия HTTP-ответа

Status Code (Код состояния): Число, сообщающее результат.
- 2xx (Success): Всё хорошо. 200 OK, 201 Created.
- 4xx (Client Error): Ошибка в запросе. 400 Bad Request, 401 Unauthorized, 404 Not Found.
- 5xx (Server Error): Сервер упал. 500 Internal Server Error, 503 Service Unavailable.
Body (Тело): Данные, которые вернул сервер (JSON, XML, HTML).

Практика: Библиотека requests

Python имеет встроенную библиотеку urllib, но в реальной работе стандартом де-факто является библиотека requests. Она проста, элегантна и делает HTTP-запросы понятными для человека.

Установка:

pip install requests

Первый запрос

Давайте попробуем получить данные с публичного тестового API.

import requests

# Отправляем GET запрос
response = requests.get("https://jsonplaceholder.typicode.com/posts/1")

# Проверяем статус код
print(response.status_code)  # Вывод: 200

# Получаем данные в формате словаря Python
data = response.json()
print(data['title'])

Объединяем с pytest

Теперь превратим это в настоящий тест. Создайте файл test_api_simple.py.

import requests
import pytest

BASE_URL = "https://jsonplaceholder.typicode.com"

def test_get_post_success():
    # Arrange & Act
    response = requests.get(f"{BASE_URL}/posts/1")

    # Assert
    assert response.status_code == 200
    data = response.json()
    assert data['id'] == 1
    assert "userId" in data

def test_create_post():
    payload = {
        "title": "foo",
        "body": "bar",
        "userId": 1
    }
    response = requests.post(f"{BASE_URL}/posts", json=payload)

    assert response.status_code == 201
    assert response.json()['title'] == "foo"

Обратите внимание: аргумент json= в методе post автоматически добавляет заголовок Content-Type: application/json и сериализует словарь в строку.

Валидация данных: JSON Schema

Проверять каждое поле вручную (assert data['id'] == 1, assert data['name'] == 'Bob') утомительно и ненадежно. Что если API вернет id как строку "1", а не число? Или забудет обязательное поле?

Для проверки структуры ответа (контракта) используют JSON Schema. Это стандарт описания формата JSON данных.

Установка библиотеки:

pip install jsonschema

Пример использования в тесте:

from jsonschema import validate

# Описываем схему ожидаемого ответа
post_schema = {
    "type": "object",
    "properties": {
        "userId": {"type": "integer"},
        "id": {"type": "integer"},
        "title": {"type": "string"},
        "body": {"type": "string"}
    },
    "required": ["userId", "id", "title"]
}

def test_get_post_schema_validation():
    response = requests.get("https://jsonplaceholder.typicode.com/posts/1")

    # Если структура не совпадет, validate выбросит исключение ValidationError
    validate(instance=response.json(), schema=post_schema)

В реальных проектах схемы часто выносят в отдельные файлы, чтобы переиспользовать их в разных тестах.

Mocking: Изоляция тестов

Интеграционные тесты хороши, но у них есть проблемы:

Нестабильность: Внешний API может упасть, и ваш тест покраснеет, хотя ваш код работает верно.
Скорость: Сетевые запросы занимают время.
Стоимость: Некоторые API платные за каждый вызов.
Сложные сценарии: Трудно заставить реальный сервер вернуть ошибку 500 по заказу.

Здесь помогает Mocking (имитация). Мы подменяем реальный вызов requests.get на нашу «куклу», которая мгновенно возвращает нужный нам ответ.

Для pytest лучшим решением является плагин pytest-mock.

Установка:

pip install pytest-mock

Пример использования фикстуры mocker

def get_user_data(user_id):
    # Функция в коде приложения, которая делает запрос
    resp = requests.get(f"https://api.example.com/users/{user_id}")
    if resp.status_code == 200:
        return resp.json()
    return None

def test_get_user_mocked(mocker):
    # 1. Создаем макет ответа
    mock_response = mocker.Mock()
    mock_response.status_code = 200
    mock_response.json.return_value = {"id": 1, "name": "Mocked Alice"}

    # 2. "Патчим" requests.get, чтобы он возвращал наш макет
    mocker.patch("requests.get", return_value=mock_response)

    # 3. Вызываем тестируемую функцию
    result = get_user_data(1)

    # 4. Проверяем результат
    assert result["name"] == "Mocked Alice"

С помощью моков вы можете проверить, как ваше приложение ведет себя, если API вернет 404, 500 или некорректный JSON, не дожидаясь реальных сбоев сервера.

Полезные ресурсы

Домашнее задание

Контекст: Вы тестируете API книжного магазина. Базовый URL: https://restful-booker.herokuapp.com (это реальный тренировочный API).

Задача 1: Создание токена (Auth) Напишите тест, который отправляет POST запрос на /auth с телом {"username": "admin", "password": "password123"}. Проверьте, что статус код 200 и в ответе есть поле token (строка).

Задача 2: CRUD операции с книгами Используя фикстуры pytest, реализуйте сценарий:

Create: Создайте бронирование (Booking) методом POST на /booking. Сохраните bookingid.
Read: Получите данные этого бронирования по ID методом GET. Проверьте, что имя совпадает с созданным.
Delete: Удалите бронирование методом DELETE (потребуется токен из Задачи 1 в заголовке Cookie: token=...).
Check: Попробуйте снова получить удаленное бронирование и убедитесь, что статус код 404.

Задача 3: Валидация схемы Опишите JSON Schema для метода GET /booking/{id} и добавьте валидацию в тест из Задачи 2.

Критерии приемки:

Используется pytest и requests.
URL вынесен в константу или фикстуру.
Тесты независимы (если возможно) или логически связаны в цепочку.
Присутствует валидация JSON Schema.

Типичные ошибки новичков

Зависимость от порядка тестов: Если тест A создает пользователя, а тест B его удаляет, то запуск только теста B приведет к ошибке. Используйте фикстуры для подготовки данных.
Хардкод URL: Не пишите http://localhost:8080 в каждом тесте. Выносите это в конфиг или conftest.py.
Игнорирование статус-кодов: Проверять только тело ответа (assert data['id'] == 1) недостаточно. Если сервер вернет 200 OK, но с текстом ошибки внутри HTML, ваш парсер JSON упадет. Всегда сначала проверяйте status_code.
Отсутствие таймаутов: В реальной жизни запросы могут зависать. Хорошей практикой считается указывать requests.get(url, timeout=5).

UI-тестирование: Playwright, Page Object Model и ожидания

Мы добрались до вершины пирамиды тестирования. Если Unit-тесты проверяют отдельные «кирпичики» кода, а API-тесты — коммуникацию между сервисами, то UI-тесты (User Interface) проверяют продукт так, как его видит конечный пользователь. Они открывают настоящий браузер, кликают по кнопкам, заполняют формы и проверяют, что верстка не «поехала», а бизнес-сценарий выполняется корректно.

Долгое время стандартом индустрии был Selenium. Однако он имеет архитектурные ограничения, приводящие к медленной работе и нестабильным тестам. В этом модуле мы изучим Playwright — современный инструмент от Microsoft, который стал де-факто стандартом для новых проектов на Python.

Цель модуля

К концу этой недели вы будете уметь:

Настраивать окружение для UI-тестирования с Playwright и pytest.
Понимать разницу между явными, неявными и автоматическими ожиданиями.
Находить элементы на странице, используя надежные (user-facing) локаторы.
Применять паттерн Page Object Model (POM) для создания масштабируемой архитектуры тестов.

Теория: Playwright против Selenium и основы архитектуры

Почему Playwright?

Selenium WebDriver работает по протоколу HTTP. Он отправляет команду драйверу (например, chromedriver), тот переводит её браузеру, браузер выполняет действие и возвращает ответ. Эта цепочка создает задержки и является причиной «мигающих» (flaky) тестов.

Playwright работает иначе. Он использует протокол отладчика (Chrome DevTools Protocol) и общается с браузером напрямую через WebSocket. Это обеспечивает высокую скорость выполнения и полный контроль над сетевыми запросами и событиями браузера.

Ключевые преимущества Playwright:

Auto-waiting (Авто-ожидание): Playwright автоматически ждет, пока элемент станет видимым, активным и кликабельным, прежде чем выполнить действие. Вам больше не нужно писать time.sleep().
Изоляция: Каждый тест запускается в новом «контексте» (Browser Context). Это аналог вкладки «инкогнито»: куки и кэш не пересекаются между тестами. Это быстрее, чем перезапускать браузер целиком.
Trace Viewer: Встроенный инструмент отладки, который записывает видео, скриншоты и сетевые запросы для каждого шага теста.

Локаторы: Как найти элемент?

Локатор — это правило поиска элемента на странице. Стабильность ваших тестов на 90% зависит от качества локаторов.

Плохие локаторы (хрупкие):

xpath=/html/body/div[2]/div/span/button — сломается при малейшем изменении верстки.
css=.btn-primary.red — сломается, если дизайнер поменяет цвет кнопки.

Хорошие локаторы (User-Facing): Playwright рекомендует искать элементы так, как их ищет пользователь (по тексту или роли).

page.get_by_role("button", name="Войти") — самый надежный вариант.
page.get_by_label("Имя пользователя") — отлично для полей ввода.
page.get_by_text("Добро пожаловать") — для проверки контента.
page.get_by_test_id("submit-order") — если разработчики добавили специальные атрибуты data-testid.

Паттерн Page Object Model (POM)

Если писать все селекторы прямо в тестах, то при изменении верстки вам придется править сотни файлов. POM решает эту проблему, разделяя логику теста и описание страницы.

Page Object — это класс, описывающий страницу (локаторы и методы взаимодействия).
Test — это сценарий, который использует методы Page Object.

Практика

Для выполнения заданий вам потребуется установленный Python и pytest.

Задача 1: Установка и первый тест

Установим библиотеки и браузеры:

pip install pytest-playwright
playwright install

Создайте файл test_login.py. Напишем простой тест для демо-сайта SauceDemo.

from playwright.sync_api import Page, expect

def test_standard_user_login(page: Page):
    # 1. Открываем страницу
    page.goto("https://www.saucedemo.com/")

    # 2. Вводим логин и пароль (используем надежные локаторы)
    # fill - очищает поле и вводит текст
    page.get_by_placeholder("Username").fill("standard_user")
    page.get_by_placeholder("Password").fill("secret_sauce")

    # 3. Кликаем кнопку логина
    page.get_by_role("button", name="Login").click()

    # 4. Проверяем, что мы перешли на страницу товаров
    # Проверяем наличие заголовка "Products"
    title = page.get_by_text("Products")

    # Assertions (проверки) в Playwright имеют встроенные ожидания
    expect(title).to_be_visible()
    expect(page).to_have_url("https://www.saucedemo.com/inventory.html")

Запустите тест командой:

pytest test_login.py --headed

Флаг --headed позволяет увидеть браузер. Без него тест пройдет в фоновом режиме (headless).

Задача 2: Работа со списками и фильтрацией

Частая задача — выбрать элемент из списка. Дополним тест сценарием добавления товара в корзину.

def test_add_backpack_to_cart(page: Page):
    page.goto("https://www.saucedemo.com/")
    page.get_by_placeholder("Username").fill("standard_user")
    page.get_by_placeholder("Password").fill("secret_sauce")
    page.get_by_role("button", name="Login").click()

    # Находим карточку товара "Sauce Labs Backpack"
    # Используем фильтрацию: ищем элемент списка, содержащий нужный текст
    product_card = page.locator(".inventory_item").filter(has_text="Sauce Labs Backpack")

    # Внутри карточки ищем кнопку "Add to cart" и кликаем
    product_card.get_by_role("button", name="Add to cart").click()

    # Проверяем, что на значке корзины появилась цифра 1
    shopping_cart_badge = page.locator(".shopping_cart_badge")
    expect(shopping_cart_badge).to_have_text("1")

Задача 3: Рефакторинг с использованием Page Object Model

Теперь превратим наш код в профессиональное решение. Создадим структуру:

project/
├── pages/
│   ├── base_page.py
│   └── login_page.py
└── tests/
    └── test_login_pom.py

1. Base Page (pages/base_page.py) Базовый класс с общими методами.

from playwright.sync_api import Page

class BasePage:
    def __init__(self, page: Page):
        self.page = page

    def open(self, url):
        self.page.goto(url)

2. Login Page (pages/login_page.py) Класс для страницы логина. Локаторы и действия инкапсулированы здесь.

from pages.base_page import BasePage

class LoginPage(BasePage):
    def __init__(self, page):
        super().__init__(page)
        # Локаторы объявляем в конструкторе или как свойства
        self.username_input = page.get_by_placeholder("Username")
        self.password_input = page.get_by_placeholder("Password")
        self.login_button = page.get_by_role("button", name="Login")
        self.error_message = page.locator("[data-test='error']")

    def login(self, username, password):
        self.username_input.fill(username)
        self.password_input.fill(password)
        self.login_button.click()

3. Тест (tests/test_login_pom.py) Тест теперь чистый и читаемый.

from pages.login_page import LoginPage
from playwright.sync_api import expect

def test_login_failure(page):
    login_page = LoginPage(page)
    login_page.open("https://www.saucedemo.com/")

    # Логика теста проста и понятна
    login_page.login("locked_out_user", "secret_sauce")

    # Проверка
    expect(login_page.error_message).to_contain_text("Sorry, this user has been locked out")

Типичные ошибки новичков

Использование time.sleep(): Никогда не используйте жесткие ожидания. Это замедляет тесты. Если Playwright не ждет элемент, используйте expect(locator).to_be_visible() или веб-ассерты.
Зависимые тесты: Каждый тест должен быть независимым. Нельзя, чтобы test_2 зависел от того, что test_1 что-то положил в корзину. Используйте фикстуры для подготовки данных.
Смешивание логики и локаторов: Не пишите page.click("#login-btn") внутри тестовой функции, если вы используете POM. Выносите это в методы страницы.
Игнорирование await: Если вы пишете асинхронные тесты (async/await), забытый await приведет к тому, что действие не выполнится, а тест пройдет ложно-положительно (или упадет позже).

Полезные ресурсы

Официальная документация Playwright Python
Генератор локаторов (Codegen) — запустите playwright codegen demo.playwright.dev/todomvc, чтобы сгенерировать код действий.
Best Practices — официальные рекомендации по написанию тестов.

Управление тестовыми данными: Faker и форматы JSON/YAML

Добро пожаловать на пятую неделю курса «Автоматизированное тестирование на Python». Мы уже научились писать тесты, взаимодействовать с API и даже начали работать с UI. Но есть одна проблема, с которой сталкивается каждый автоматизатор, как только количество тестов переваливает за десяток: данные.

Представьте, что вы написали тест регистрации пользователя. Вы использовали email test@example.com. Тест прошел успешно. Вы запускаете его второй раз, и он падает с ошибкой: «Пользователь с таким email уже существует». Вы меняете email на test2@example.com. А что делать на сотый раз?

В этой статье мы разберем, как перестать хардкодить данные, как генерировать реалистичную информацию на лету с помощью библиотеки Faker и как вынести конфигурацию и тестовые наборы в внешние файлы форматов JSON и YAML.

Цель модуля

К концу этой недели вы будете уметь:

Генерировать уникальные и реалистичные данные (имена, адреса, карты) с помощью Faker.
Понимать разницу между статическими и динамическими данными.
Делать тесты воспроизводимыми с помощью seeding.
Читать и писать файлы в форматах JSON и YAML в Python.
Разделять логику теста и тестовые данные (Data-Driven Testing).

Теория

1. Проблема тестовых данных

В автоматизации данные делятся на два типа:

Статические данные: Константы, которые редко меняются (URL стенда, логин администратора, список категорий товаров).
Динамические данные: Уникальные значения для каждого запуска (email нового пользователя, номер заказа, текст комментария).

Хардкод (жесткое прописывание данных в коде) — это зло. Он делает тесты хрупкими и зависимыми друг от друга. Хороший тест должен быть изолированным: он сам создает свои данные и сам их удаляет (или они уникальны и не мешают другим).

2. Библиотека Faker

Faker — это мощная библиотека для генерации поддельных данных. Она позволяет создавать имена, адреса, тексты, банковские карты, даты и многое другое. Главное преимущество — данные выглядят как настоящие, что позволяет проходить валидацию на бэкенде и фронтенде.

Установка:

pip install Faker

Базовое использование

from faker import Faker

fake = Faker()

print(fake.name())    # Пример: John Doe
print(fake.address()) # Пример: 426 Jordy Lodge
print(fake.text())    # Пример: Lorem ipsum dolor sit amet...

Локализация

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

fake = Faker("ru_RU")

print(fake.name())         # Пример: Иван Иванович Иванов
print(fake.phone_number()) # Пример: +7 (999) 123-45-67

Детерминизм (Seeding)

Одна из проблем случайных данных — flaky-тесты (мигающие тесты). Представьте, что Faker сгенерировал имя с апострофом O'Connor, и ваш сайт упал из-за SQL-инъекции. Вы перезапускаете тест, Faker генерирует Smith, и тест проходит. Вы не можете воспроизвести баг.

Чтобы этого избежать, используется seed (зерно). Если установить seed, последовательность генерации будет всегда одинаковой.

fake = Faker()
Faker.seed(4321)

print(fake.name()) # Всегда будет одно и то же имя при каждом запуске скрипта

3. Форматы хранения данных: JSON и YAML

Хранить большие объемы статических данных (например, тело сложного запроса или конфиг окружения) прямо в .py файле неудобно. Для этого используют форматы сериализации.

JSON (JavaScript Object Notation)

Стандарт де-факто для REST API. Python имеет встроенную поддержку.

Плюсы: Родной формат для веб-сервисов, строгий синтаксис.
Минусы: Нет комментариев, строгие правила (запятые, кавычки), плохая читаемость больших файлов.

Пример data.json:

{
  "browser": "chrome",
  "timeout": 30,
  "users": [
    {"id": 1, "role": "admin"},
    {"id": 2, "role": "guest"}
  ]
}

YAML (YAML Ain't Markup Language)

Стандарт для конфигурационных файлов (Docker, Kubernetes, CI/CD, настройки фреймворков).

Плюсы: Очень чистый синтаксис, поддержка комментариев, меньше скобок.
Минусы: Зависимость от отступов (как в Python), требует установки библиотеки PyYAML.

Пример config.yaml:

# Настройки браузера
browser: chrome
timeout: 30

users:
  - id: 1
    role: admin
  - id: 2
    role: guest

Установка библиотеки для YAML:

pip install PyYAML

Практика

Перейдем к коду. Мы создадим модуль генерации данных и научимся загружать конфиги.

Задача 1: Генератор пользователей с Faker

Создадим класс, который генерирует данные для регистрации. Это полезно для паттерна Object Mother или Data Builder.

from faker import Faker

fake = Faker("ru_RU")

class UserData:
    def __init__(self, name, email, password, age):
        self.name = name
        self.email = email
        self.password = password
        self.age = age

    def __repr__(self):
        return f"User(name={self.name}, email={self.email})"

def generate_user():
    # Генерируем данные
    # Используем domain_name, чтобы email выглядел валидно
    email = fake.email()

    return UserData(
        name=fake.name(),
        email=email,
        password=fake.password(length=12),
        age=fake.random_int(min=18, max=90)
    )

# Проверка
user = generate_user()
print(f"Сгенерирован пользователь: {user}")

Задача 2: Работа с JSON

Допустим, у нас есть файл payloads.json, где хранятся шаблоны ответов от API, которые мы используем для моков (mocking).

import json
import os

# Функция для загрузки данных
def load_json_data(filename):
    # Получаем абсолютный путь к файлу, чтобы тест запускался из любой папки
    current_dir = os.path.dirname(__file__)
    file_path = os.path.join(current_dir, filename)

    with open(file_path, 'r', encoding='utf-8') as f:
        return json.load(f)

# Использование
data = load_json_data("payloads.json")
print(f"Тип данных: {type(data)}") # <class 'dict'>
print(data['users'][0]['role'])

Задача 3: Конфигурация через YAML

Создадим файл config.yaml и напишем фикстуру pytest, которая делает эти настройки доступными во всех тестах.

Файл config.yaml:

base_url: "https://api.dev.example.com"
db:
  host: "localhost"
  port: 5432

Файл conftest.py:

import pytest
import yaml
import os

@pytest.fixture(scope="session")
def config():
    path = os.path.join(os.path.dirname(__file__), "config.yaml")
    with open(path, "r") as f:
        return yaml.safe_load(f)

# Пример теста в файле test_something.py
def test_environment(config):
    print(f"Testing on {config['base_url']}")
    assert config['db']['port'] == 5432

Задача 4: Комбинируем подходы

Частая задача: взять шаблон JSON и заменить в нем пару полей на динамические данные от Faker.

import json
from faker import Faker

fake = Faker()

def get_registration_payload():
    # 1. Загружаем шаблон (обычно из файла, тут для краткости строка)
    template_json = '{"username": "", "email": "", "is_active": true}'
    payload = json.loads(template_json)

    # 2. Обогащаем динамическими данными
    payload["username"] = fake.user_name()
    payload["email"] = fake.email()

    return payload

print(get_registration_payload())

Домашнее задание

Контекст: Вы тестируете интернет-магазин. Вам нужно проверять создание заказов.

Задание:

Создайте файл test_data.yaml, содержащий список товаров (статические данные): название, цена, категория.
Напишите класс OrderBuilder, который использует Faker для генерации адреса доставки и имени клиента.
Реализуйте функцию create_order_json, которая:
- Читает товары из YAML.
- Выбирает случайный товар.
- Генерирует данные клиента через Faker.
- Сохраняет итоговый заказ в файл order_<timestamp>.json.
Напишите тест (можно без реальной отправки запроса), который вызывает эту функцию и проверяет, что в созданном JSON файле есть поле total_price (цена товара + стоимость доставки, которую можно придумать).

Критерии приемки:

Используется yaml.safe_load.
Используется Faker с локалью ru_RU.
Код разбит на функции/классы.
Файлы создаются и читаются без ошибок кодировки.

Типичные ошибки новичков

Случайность без логирования: Тест упал на специфических данных от Faker, но вы не вывели их в консоль/отчет. Вы не знаете, на каких именно данных упал тест. Решение: Всегда логируйте сгенерированные данные перед шагом Act.
JSON с комментариями: Попытка добавить комментарий // или # в .json файл приведет к ошибке парсинга. JSON не поддерживает комментарии.
Забытый __init__.py: При попытке импортировать данные из соседней папки Python не видит модуль. Убедитесь, что пакеты инициализированы.
Сложная логика генерации: Если ваш генератор данных занимает 100 строк и имеет кучу условий if/else, вам придется писать тесты на ваши тесты. Держите генераторы простыми.

Полезные ресурсы

В следующем модуле мы займемся инфраструктурой: настроим pytest.ini, научимся логировать действия и генерировать красивые отчеты Allure.

Инфраструктура: конфигурация, логирование и отчеты Allure

Добро пожаловать на шестую неделю курса. Мы уже умеем писать функциональные тесты для API и UI, генерировать данные и использовать моки. Но представьте ситуацию: у вас 500 тестов, они запускаются ночью в CI/CD, и утром вы видите, что 50 из них упали. В консоли — мешанина из ошибок, принтов и трейсбеков. Менеджер спрашивает: «Насколько стабилен релиз?», а вы не можете ответить, пока не разберете логи вручную.

Отличие Junior от Senior специалиста часто кроется не в умении написать тест, а в умении построить инфраструктуру, которая делает результаты тестирования прозрачными, а отладку — быстрой. Сегодня мы превратим ваш тестовый проект в профессиональный инструмент с помощью глобальной конфигурации, правильного логирования и интерактивных отчетов Allure.

Цель модуля

К концу этого занятия вы настроите проект так, чтобы:

Запуск тестов выполнялся одной короткой командой pytest.
Вместо print() использовалось структурированное логирование, сохраняемое в файл.
Генерировался красивый HTML-отчет с историей запусков.
К упавшим UI-тестам автоматически прикреплялись скриншоты, а к API-тестам — дампы запросов.

1. Конфигурация: pytest.ini

Вы наверняка устали каждый раз писать в терминале длинные команды вроде:

pytest -v -s --tb=short --strict-markers

Файл pytest.ini — это центр управления полетами вашего проекта. Он позволяет зафиксировать настройки запуска, зарегистрировать маркеры и определить переменные окружения.

Практика: Создание конфигурации

Создайте файл pytest.ini в корне вашего проекта. Это позволит стандартизировать запуск тестов для всей команды.

[pytest]
# Параметры командной строки, которые добавляются автоматически при запуске pytest
# -v: подробный вывод
# -s: вывод stdout (print/log) в консоль
# --tb=short: сокращенный формат трейсбека ошибки (меньше шума)
# --alluredir=allure-results: папка для сохранения результатов отчета
addopts =
    -v
    -s
    --tb=short
    --alluredir=allure-results

# Где искать тесты (ускоряет сбор тестов, исключая папки venv и др.)
testpaths = tests

# Шаблоны имен файлов тестов
python_files = test_*.py *_test.py

# Регистрация кастомных маркеров, чтобы избежать Warning
markers =
    smoke: критические проверки
    regression: полный цикл тестирования
    slow: медленные тесты (более 10с)
    api: тесты API
    ui: тесты интерфейса

# Минимально требуемая версия pytest
minversion = 7.0

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

Важно: Никогда не храните в pytest.ini секреты (пароли, токены). Этот файл попадает в репозиторий. Для секретов используйте библиотеку python-dotenv и файлы .env, добавленные в .gitignore.

Полезные ссылки:

Документация по конфигурации pytest

2. Логирование: почему print — это плохо

Новички используют print(), чтобы понять, что происходит в тесте. Профессионалы используют модуль logging. Почему?

Уровни важности: Вы можете отфильтровать вывод. DEBUG — для разработки, INFO — для отчета, ERROR — для алертов.
Контекст: Логи автоматически добавляют время, имя файла и номер строки.
Потоки: print может смешиваться в кашу при параллельном запуске тестов (pytest-xdist), а logging потокобезопасен.
Гибкость: Логи можно одновременно писать в консоль, в файл и отправлять в систему мониторинга (Sentry/ELK).

Практика: Настройка логирования в pytest.ini

Добавьте секцию логирования в ваш pytest.ini. Это активирует встроенный плагин логирования pytest.

[pytest]
# ... (предыдущие настройки)

# --- Настройки Live Logs (то, что видно в консоли) ---
log_cli = true
log_cli_level = INFO
log_cli_format = %(asctime)s [%(levelname)s] %(message)s
log_cli_date_format = %H:%M:%S

# --- Настройки файла логов (артефакт для разбора полетов) ---
log_file = pytest.log
log_file_level = DEBUG
log_file_format = %(asctime)s [%(levelname)s] %(name)s: %(message)s
log_file_date_format = %Y-%m-%d %H:%M:%S

Использование в коде

В тестах и фикстурах мы создаем экземпляр логгера.

import logging
import pytest

# Получаем логгер с именем текущего файла
logger = logging.getLogger(__name__)

def test_login_process():
    logger.info("Начинаем тест авторизации")

    login = "admin"
    # DEBUG попадет только в файл pytest.log, не засоряя консоль
    logger.debug(f"Используем логин: {login}")

    try:
        # Эмуляция действия
        assert 1 == 1
        logger.info("Авторизация успешна")
    except AssertionError:
        logger.error("Ошибка авторизации! Критический сбой.")
        raise

3. Отчеты Allure: Визуализация качества

Стандартный вывод pytest (.F..) понятен инженеру, но бесполезен для бизнеса. Allure Framework — это стандарт индустрии для построения красивых, интерактивных отчетов.

Установка

Вам понадобятся две вещи:

Библиотека Python: pip install allure-pytest
Утилита командной строки Allure (требует Java).
- macOS: brew install allure
- Windows: scoop install allure или скачать архив с официального GitHub релиза.

Разметка тестов (Allure Decorators)

Чтобы отчет был читаемым, тесты нужно «размечать». Это помогает группировать их по функционалу.

import allure
import pytest

@allure.feature("Модуль корзины")
@allure.story("Добавление товара")
@allure.severity(allure.severity_level.CRITICAL)
@allure.link("https://jira.company.com/browse/QA-123", name="Jira Task")
def test_add_item_to_cart():
    with allure.step("Открыть главную страницу"):
        # open_page()
        pass

    with allure.step("Нажать кнопку 'Купить'"):
        # click_buy()
        pass

    with allure.step("Проверить счетчик корзины"):
        assert 1 == 1

Генерация отчета

Запустите тесты: pytest (благодаря pytest.ini флаг --alluredir применится сам).
В папке allure-results появятся JSON-файлы. Это «сырые» данные.
Сгенерируйте и откройте отчет одной командой:
```
allure serve allure-results
```

Браузер откроет дашборд с графиками, временем выполнения и списком тестов.

4. Продвинутая практика: Hooks и conftest.py

Самая мощная часть Allure — возможность автоматически прикреплять данные при падении теста. Никто не хочет перезапускать упавший тест, чтобы увидеть ошибку. Мы хотим видеть скриншот момента падения сразу в отчете.

Для этого мы используем файл conftest.py и хуки pytest.

Задача: Автоматический скриншот при падении

Добавьте этот код в ваш conftest.py:

import pytest
import allure
from selenium import webdriver # Если используете Selenium

@pytest.hookimpl(tryfirst=True, hookwrapper=True)
def pytest_runtest_makereport(item, call):
    """
    Хук, который срабатывает после выполнения каждого теста.
    Позволяет получить статус теста (passed/failed) и прикрепить данные.
    """
    # Выполняем исходный код хука и получаем результат
    outcome = yield
    rep = outcome.get_result()

    # Проверяем, что это этап вызова теста (call), а не setup или teardown
    if rep.when == "call" and rep.failed:

        # Пытаемся достать драйвер из фикстуры (если он там есть)
        # Предполагаем, что в тесте есть фикстура 'browser' или 'driver'
        driver = item.funcargs.get('driver')

        if driver:
            allure.attach(
                driver.get_screenshot_as_png(),
                name="Screenshot on Failure",
                attachment_type=allure.attachment_type.PNG
            )

        # Также можно прикрепить логи консоли или текст ошибки
        allure.attach(
            str(item.location),
            name="Location",
            attachment_type=allure.attachment_type.TEXT
        )

Теперь, если UI-тест упадет, в отчете Allure во вкладке теста появится скриншот.

Типичные ошибки новичков

Отсутствие pytest.ini: Каждый разработчик запускает тесты со своими флагами, что приводит к разным результатам.
print вместо логгера: На CI сервере логи теряются или смешиваются, делая отладку невозможной.
Хранение отчетов в Git: Папку allure-results и allure-report нужно добавить в .gitignore. В репозитории должен быть только код.
Слишком много шагов: Не нужно оборачивать в with allure.step каждую строчку кода. Выделяйте только логические блоки (например, "Авторизация", "Заполнение формы").
Абсолютные пути: Указание путей к логам или драйверам как C:\Users\Admin\project сломает тесты у коллеги. Используйте pathlib и относительные пути.

Итоги модуля

Теперь ваша инфраструктура выглядит профессионально:

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

В следующем модуле мы перейдем к CI/CD и научимся запускать эти тесты автоматически в GitHub Actions.

CI/CD: автоматизация запуска тестов в GitHub Actions

Мы прошли долгий путь: от написания первой функции на Python до создания сложной архитектуры с UI, API тестами и генерацией отчетов. Но пока что все эти тесты запускаются вручную на вашем локальном компьютере. В реальной разработке фраза «у меня локально всё работает» — это не аргумент.

Представьте команду из 10 разработчиков. Каждый день они вносят изменения в код. Если они забудут запустить тесты перед слиянием кода (merge), проект сломается. Если у одного разработчика Python 3.10, а у другого 3.12 — поведение может отличаться.

Здесь на помощь приходит CI/CD. В этой статье мы автоматизируем запуск ваших тестов с помощью GitHub Actions, чтобы они проверяли код при каждом сохранении.

Что такое CI/CD?

Это акроним, объединяющий две практики:

CI (Continuous Integration — Непрерывная интеграция): Практика частой сборки проекта и запуска автотестов. Главная цель — как можно раньше найти баги. Если тесты упали, изменения отклоняются.
CD (Continuous Delivery / Deployment — Непрерывная доставка): Автоматическая выкладка проверенного кода на боевые серверы (Production).

Для QA-инженера (особенно автоматизатора) критически важна часть CI. Наша задача — настроить «робота», который будет беспристрастно проверять код 24/7.

Почему GitHub Actions?

Существует множество инструментов: Jenkins, GitLab CI, TeamCity, CircleCI. Однако GitHub Actions (GHA) стал стандартом де-факто для проектов, хостящихся на GitHub, по нескольким причинам:

Интеграция: Не нужно настраивать отдельные серверы, всё работает внутри GitHub.
Бесплатно: Для публичных репозиториев (и щедрые лимиты для приватных).
Конфигурация как код: Весь процесс описывается в YAML-файле, который лежит в вашем репозитории.

Анатомия GitHub Actions

Чтобы «магия» заработала, нужно создать файл конфигурации. GitHub ищет их в специальной папке: .github/workflows/.

Основные понятия:

Workflow (Рабочий процесс): Весь файл конфигурации. Запускается по событию (например, push).
Job (Задача): Набор шагов, выполняемых на одной виртуальной машине.
Runner (Раннер): Виртуальный сервер (обычно Ubuntu), который GitHub выделяет для выполнения вашей задачи.
Step (Шаг): Конкретное действие (команда в терминале или готовый экшен).

Практика: Создаем первый пайплайн

Давайте настроим автоматический запуск тестов pytest при каждом пуше в ветку main или при создании Pull Request.

Шаг 1: Структура файла

Создайте в корне проекта папку .github, внутри неё папку workflows, а в ней файл tests.yml.

name: Automated Tests

# События, которые запускают пайплайн
on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main

jobs:
  test:
    name: Run Pytest
    runs-on: ubuntu-latest  # Выбираем ОС для раннера

    steps:
      # Здесь будут наши шаги

Шаг 2: Получение кода и настройка окружения

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

Мы будем использовать готовые Actions (экшены) от сообщества и самого GitHub. Это как библиотеки, только для CI.

Дополним секцию steps:

    steps:
      # 1. Скачиваем код репозитория
      - name: Checkout code
        uses: actions/checkout@v4

      # 2. Устанавливаем Python
        # Используем официальный экшен для настройки Python
      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: '3.10'  # Указываем нужную версию

      # 3. Устанавливаем зависимости
      - name: Install dependencies
        run: |
          python -m pip install --upgrade pip
          pip install -r requirements.txt

Обратите внимание на синтаксис run: |. Вертикальная черта позволяет писать многострочные команды bash.

Шаг 3: Запуск тестов

Теперь, когда окружение готово, мы можем запустить pytest. Вспомним про наш файл pytest.ini, который мы настроили в прошлом модуле — он автоматически подхватит настройки.

      # 4. Запускаем тесты
      - name: Run tests with Pytest
        run: pytest

Полный файл конфигурации

Вот как выглядит итоговый файл .github/workflows/tests.yml:

name: Automated Tests

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  build-and-test:
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v4

    - name: Set up Python 3.10
      uses: actions/setup-python@v5
      with:
        python-version: "3.10"

    - name: Install dependencies
      run: |
        python -m pip install --upgrade pip
        if [ -f requirements.txt ]; then pip install -r requirements.txt; fi

    - name: Run tests
      run: pytest --alluredir=allure-results

Теперь сделайте коммит и отправьте его на GitHub (git push). Перейдите во вкладку Actions в вашем репозитории. Вы увидите, как запустился ваш workflow. Если тесты пройдут успешно — он станет зеленым.

Работа с артефактами: Сохраняем отчеты

Одна из главных проблем CI: когда раннер завершает работу, он уничтожается вместе со всеми файлами. Если тесты упали, и вы сгенерировали отчет Allure или логи, они исчезнут.

Чтобы сохранить файлы после завершения работы, используются Artifacts.

Добавим шаг сохранения результатов Allure:

    - name: Upload Allure Results
      if: always()  # Выполнять, даже если тесты упали
      uses: actions/upload-artifact@v4
      with:
        name: allure-results
        path: allure-results/
        retention-days: 5

Разбор:

if: always(): Критически важно. По умолчанию, если шаг с тестами падает (exit code != 0), следующие шаги не выполняются. Но нам нужен отчет именно тогда, когда тесты упали!
path: Путь к папке, которую нужно сохранить.

Теперь после прогона в интерфейсе GitHub Actions внизу страницы появится zip-архив с результатами, который можно скачать.

Продвинутые техники

1. Матрица тестирования (Matrix Build)

Что если вы пишете библиотеку и хотите убедиться, что она работает и на Python 3.9, и на 3.12? Не нужно копировать джобы. Используйте стратегию matrix.

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        python-version: ["3.9", "3.10", "3.11", "3.12"]

    steps:
    - uses: actions/checkout@v4
    - name: Set up Python ${{ matrix.python-version }}
      uses: actions/setup-python@v5
      with:
        python-version: ${{ matrix.python-version }}
    # ... остальные шаги

GitHub запустит 4 параллельных джобы, по одной для каждой версии.

2. Кэширование зависимостей

Установка requirements.txt может занимать минуты. Чтобы ускорить процесс, можно кэшировать скачанные пакеты.

В setup-python это делается одной строчкой:

    - uses: actions/setup-python@v5
      with:
        python-version: '3.10'
        cache: 'pip' # Кэширование pip пакетов

Branch Protection Rules

Настройка CI — это полдела. Нужно запретить вливать код, который не прошел тесты.

Зайдите в настройки репозитория (Settings).
Выберите Branches -> Add branch protection rule.
Укажите паттерн ветки (обычно main).
Поставьте галочку Require status checks to pass before merging.
Найдите в поиске название вашей джобы (например, build-and-test).

Теперь кнопка "Merge" будет заблокирована, пока GitHub Actions не загорится зеленым.

Типичные ошибки новичков

Неправильные отступы в YAML: YAML крайне чувствителен к пробелам (как Python). Если отступ сбит, пайплайн не запустится. Используйте линтеры или IDE.
Отсутствие requirements.txt: Раннер не знает, какие библиотеки нужны вашему проекту. Не забывайте обновлять файл зависимостей (pip freeze > requirements.txt) и коммитить его.
Хардкод переменных: Если ваши тесты требуют пароль от БД, не пишите его в YAML. Используйте GitHub Secrets (Settings -> Secrets and variables -> Actions) и обращайтесь к ним как ${{ secrets.DB_PASSWORD }}.
Забытый if: always(): Тесты упали, вы хотите посмотреть почему, а отчет не загрузился, потому что шаг загрузки артефактов был пропущен из-за ошибки в предыдущем шаге.

Домашнее задание

Контекст: У вас есть репозиторий с проектом, содержащим UI и API тесты.

Задание:

Создайте файл .github/workflows/ci.yml.
Настройте запуск тестов на события push и pull_request.
Добавьте шаг установки зависимостей с кэшированием.
Настройте сохранение папки allure-results и файла pytest.log (если вы настроили логирование в файл) в качестве артефактов.
Сделайте Pull Request с заведомо падающим тестом и убедитесь, что GitHub пометил проверку как неудачную (красный крестик), но артефакты всё равно загрузились.

Критерии приемки:

Пайплайн успешно запускается.
Используется actions/checkout и actions/setup-python.
Артефакты доступны для скачивания в интерфейсе GitHub.

Полезные ресурсы

Официальная документация GitHub Actions
Python in GitHub Actions
GitHub Actions Marketplace — поиск готовых экшенов.

В следующем модуле мы упакуем наши тесты в Docker, чтобы они работали идентично на любой машине, независимо от установленной ОС.

Контейнеризация: Docker и Docker Compose для тестов

Добро пожаловать на восьмую неделю курса «Автоматизированное тестирование на Python». В прошлом модуле мы настроили CI/CD в GitHub Actions и увидели, как удобно запускать тесты в облаке. Но заметили ли вы одну деталь? GitHub Actions каждый раз выделяет нам «чистую» виртуальную машину, на которую мы заново устанавливаем Python и зависимости.

А что, если тесты нужно запустить локально, но у коллеги стоит Python 3.8, у вас 3.11, а на сервере вообще Linux без графической оболочки? Или вашим тестам нужна конкретная версия базы данных PostgreSQL, которую долго и сложно устанавливать вручную?

Здесь на помощь приходит контейнеризация. Сегодня мы научимся упаковывать наши автотесты в Docker, чтобы они работали идентично на любой машине — будь то ноутбук разработчика, сервер тестировщика или CI-пайплайн. Мы избавимся от проблемы «на моем компьютере всё работает» раз и навсегда.

Цель модуля

К концу этой недели вы будете уметь:

Понимать разницу между виртуальной машиной и контейнером.
Писать Dockerfile для проекта с автотестами.
Использовать Docker Compose для поднятия тестовой инфраструктуры (тесты + тестируемое приложение + база данных).
Настраивать сетевое взаимодействие между контейнерами.
Получать отчеты (Allure) из изолированного контейнера на хост-машину.

Теория: Что такое Docker?

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

Docker предлагает другой подход: вы упаковываете всё содержимое комнаты в стандартный железный морской контейнер. Грузчикам (операционной системе) всё равно, что внутри — пианино или коробки с книгами. Они просто грузят контейнер. Если он поместился на корабль в порту отправления, он гарантированно поместится на такой же корабль в порту назначения.

В мире IT:

Приложение (или тесты) — это груз.
Docker Image (Образ) — это запечатанный контейнер с описью содержимого.
Docker Container — это запущенный процесс, работающий внутри этого изолированного пространства.

Основные понятия

Dockerfile: Текстовая инструкция (рецепт), как собрать образ. Например: «Возьми Python, скопируй туда мой код, установи библиотеки».
Image (Образ): Неизменяемый файл, результат сборки Dockerfile. Это «слепок» системы. Образы хранятся в реестрах (например, Docker Hub).
Container (Контейнер): Живой экземпляр образа. Вы можете запустить 10 контейнеров из одного образа одновременно.
Volume (Том): Способ «пробросить» папку с вашего компьютера внутрь контейнера или наоборот. Это нужно, чтобы данные (например, отчеты тестов) не исчезли после удаления контейнера.

Docker Compose

Если Docker запускает один контейнер, то Docker Compose — это дирижер оркестра. Он позволяет описать в одном YAML-файле сразу несколько сервисов (например, web-app, database, tests) и запустить их одной командой. Compose автоматически настраивает сеть, чтобы контейнеры «видели» друг друга по именам.

Полезные ресурсы:

Практика

Для работы вам понадобится установленный Docker Desktop (для Windows/Mac) или Docker Engine (для Linux).

Задача 1: Пишем Dockerfile для тестов

Допустим, у нас есть стандартный проект с тестами:

my_tests/
├── tests/
│   └── test_api.py
├── requirements.txt
├── pytest.ini
└── Dockerfile  <-- Создадим этот файл

Создайте файл с именем Dockerfile (без расширения) в корне проекта:

# 1. Базовый образ. Используем slim версию, она легче.
FROM python:3.10-slim

# 2. Устанавливаем рабочую директорию внутри контейнера
WORKDIR /app

# 3. Копируем файл зависимостей
COPY requirements.txt .

# 4. Устанавливаем зависимости
# --no-cache-dir уменьшает размер образа
RUN pip install --no-cache-dir -r requirements.txt

# 5. Копируем весь остальной код проекта в /app
COPY . .

# 6. Команда по умолчанию при запуске контейнера
CMD ["pytest", "-v"]

Важный момент: Чтобы не копировать лишнее (виртуальное окружение .venv, кэш __pycache__, .git), создайте файл .dockerignore рядом с Dockerfile:

.git
.venv
__pycache__
.pytest_cache
allure-results

Теперь соберем образ. Откройте терминал в папке проекта:

# -t задает имя (тег) образа
# Точка в конце означает "искать Dockerfile в текущей папке"
docker build -t my-test-image .

После успешной сборки запустим тесты:

docker run --rm my-test-image

Флаг --rm означает «удалить контейнер сразу после завершения работы». Вы увидите вывод pytest прямо в консоли, как будто запускали его локально.

Задача 2: Сохранение отчетов (Volumes)

Если тесты упадут или сгенерируют отчет Allure, эти файлы останутся внутри контейнера. Как только контейнер остановится, файлы исчезнут. Нам нужно «вытащить» их наружу.

Используем механизм Volumes (томов).

# Синтаксис: -v путь_на_хосте:путь_в_контейнере
docker run --rm -v $(pwd)/allure-results:/app/allure-results my-test-image pytest --alluredir=allure-results

Теперь, после прогона тестов, папка allure-results на вашем компьютере наполнится JSON-файлами из контейнера.

Задача 3: Docker Compose для интеграционных тестов

Представьте более сложный сценарий. Ваши тесты проверяют API, которое работает с базой данных. Чтобы запустить тесты, вам нужно:

Поднять базу данных (PostgreSQL).
Поднять само приложение (API).
Запустить тесты, которые будут стучаться в это API.

Вручную это делать долго. Опишем инфраструктуру в docker-compose.yml.

version: '3.8'

services:
  # Сервис 1: Тестируемое приложение (System Under Test)
  sut:
    image: my-web-app:latest  # Предположим, образ приложения уже есть
    ports:
      - "8000:8000"
    environment:
      - DB_HOST=db  # Важно! Имя хоста совпадает с именем сервиса ниже
    depends_on:
      - db

  # Сервис 2: База данных
  db:
    image: postgres:15-alpine
    environment:
      POSTGRES_USER: user
      POSTGRES_PASSWORD: password
      POSTGRES_DB: test_db

  # Сервис 3: Наши тесты
  tests:
    build: .  # Собираем образ из текущей папки (наш Dockerfile)
    depends_on:
      - sut
    # Переопределяем команду запуска, чтобы указать URL приложения
    # Обратите внимание: вместо localhost мы пишем http://sut:8000
    command: pytest --base-url=http://sut:8000
    volumes:
      - ./allure-results:/app/allure-results

Ключевой момент: Сеть (Networking)

Внутри Docker Compose не работает localhost так, как вы привыкли.

Если тесты пишут requests.get("http://localhost:8000"), они стучатся в свой собственный контейнер, где никакого API нет.
Чтобы достучаться до соседнего контейнера, нужно использовать его имя сервиса как хостнейм. В нашем случае: http://sut:8000.

Запуск всей системы:

# --build пересобирает образы, если код изменился
# --abort-on-container-exit останавливает всё, когда тесты (или любой контейнер) завершатся
docker-compose up --build --abort-on-container-exit

Задача 4: Проблема ожидания (Wait-for-it)

Если вы запустите конфигурацию выше, тесты могут упасть сразу же. Почему? Потому что контейнер db и sut запустились, но приложению нужно время (секунды), чтобы инициализировать базу данных и начать принимать запросы. А тесты стартуют мгновенно.

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

Решение: использовать скрипты ожидания или логику retry внутри тестов.

Простой способ в Python (в conftest.py):

import pytest
import requests
import time
from requests.exceptions import ConnectionError

@pytest.fixture(scope="session", autouse=True)
def wait_for_api():
    url = "http://sut:8000/health"  # Эндпоинт проверки здоровья
    timeout = 30
    start = time.time()

    while time.time() - start < timeout:
        try:
            response = requests.get(url)
            if response.status_code == 200:
                return
        except ConnectionError:
            pass
        time.sleep(1)

    pytest.fail("API did not start in time")

Домашнее задание

Контекст: Используйте проект с API-тестами из 3-й недели (Bookstore API или любой публичный API).

Задание:

Напишите Dockerfile для вашего проекта. Убедитесь, что используете .dockerignore.
Создайте docker-compose.yml, в котором будет только один сервис — tests.
Настройте Volume так, чтобы после прогона команды docker-compose up у вас на локальном компьютере в папке report/ появлялся сгенерированный HTML отчет Allure (вам понадобится команда allure generate внутри контейнера или просто сохранение allure-results для генерации локально).
Усложнение: Добавьте в Compose сервис selenium/standalone-chrome и настройте ваши UI-тесты (если есть) на использование Remote WebDriver, указывающего на этот контейнер.

Критерии приемки:

Команда docker-compose up успешно прогоняет тесты и завершается.
В консоли видны логи тестов.
На хост-машине появляются файлы результатов.
В коде тестов нет хардкода локальных путей.

Типичные ошибки новичков

Использование localhost внутри контейнера: Самая частая ошибка. Запомните: внутри контейнера localhost — это сам контейнер. Чтобы обратиться к хост-машине (вашему ноутбуку), на Windows/Mac используйте адрес host.docker.internal. Чтобы обратиться к другому сервису в Compose — используйте имя сервиса.
Копирование виртуального окружения: Если не добавить .venv в .dockerignore, Docker скопирует вашу локальную папку с библиотеками (которая может быть создана на Windows) в Linux-контейнер. Это приведет к странным ошибкам. Всегда устанавливайте зависимости заново внутри Dockerfile.
Запуск от root: По умолчанию Docker запускает процессы от root. В реальных проектах (особенно в банках) это запрещено безопасностью. Хорошей практикой считается создание пользователя: RUN useradd -m myuser && USER myuser.
Тяжелые образы: Использование FROM python:3.10 (полная версия) вместо slim или alpine может увеличить размер образа с 100 МБ до 1 ГБ. Для тестов лучше использовать python:3.10-slim.

В следующем модуле мы поговорим о продвинутых практиках: как ускорить тесты с помощью параллельного запуска и как писать сложные плагины для pytest.

Продвинутый pytest: параллельный запуск и кастомные плагины

Добро пожаловать на девятую неделю курса «Автоматизированное тестирование на Python». Мы уже прошли огромный путь: от простых функций до упаковки тестов в Docker-контейнеры. Ваша инфраструктура работает, тесты запускаются в CI/CD, и отчеты Allure радуют глаз.

Но по мере роста проекта возникает новая проблема: время. Когда тестов становится 500, 1000 или 5000, их последовательное выполнение может занимать часы. Ждать час, чтобы узнать, что ты пропустил запятую в коде — непозволительная роскошь. Кроме того, по мере усложнения логики вам может потребоваться функционал, которого нет в стандартном pytest.

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

Цель модуля

К концу этой недели вы будете уметь:

Ускорять выполнение тестов с помощью библиотеки pytest-xdist.
Решать проблемы состояния гонки (race conditions) при параллельном запуске.
Понимать архитектуру хуков (hooks) в pytest.
Писать собственные локальные и устанавливаемые плагины.
Управлять порядком выполнения и фильтрацией тестов через код.

Часть 1: Параллельный запуск с pytest-xdist

По умолчанию pytest запускает тесты последовательно: один за другим, в одном процессе. Это надежно, но медленно. Современные процессоры имеют много ядер, и большую часть времени при последовательном запуске эти ядра простаивают.

Плагин pytest-xdist позволяет запускать тесты параллельно, используя несколько процессов (workers). Каждый воркер — это, по сути, отдельный мини-pytest, который берет порцию тестов из общей очереди и выполняет их.

Установка и запуск

Установим плагин:

pip install pytest-xdist

Теперь у нас появился флаг -n (numprocesses).

Запуск в 4 потока:

pytest -n 4

Автоматическое определение количества ядер (рекомендуется):

pytest -n auto

Главная проблема: Изоляция данных

Параллелизация — это лакмусовая бумажка качества ваших тестов. Если при запуске pytest -n auto ваши тесты начинают падать хаотично (то падают, то проходят), значит, они не изолированы.

Типичный сценарий провала:

Тест А (Воркер 1): Создает пользователя admin в базе данных.
Тест Б (Воркер 2): Проверяет, что список пользователей пуст, и очищает базу.
Тест А: Пытается залогиниться под admin, но Тест Б его уже удалил.
Результат: Ошибка UserNotFound.

Правило: Тесты, запускаемые параллельно, не должны зависеть от общего изменяемого состояния (одна и та же запись в БД, один и тот же файл, глобальные переменные).

Решение проблем с фикстурами (Scope Session)

В pytest-xdist есть нюанс: фикстуры с областью видимости scope="session" создаются для каждого воркера отдельно. Если ваша фикстура поднимает тяжелую базу данных, и у вас 4 воркера, база поднимется 4 раза. Это может убить производительность.

Чтобы выполнить настройку один раз для всех процессов, используется файловая блокировка (File Lock). Pytest предоставляет фикстуру tmp_path_factory, которая помогает синхронизировать процессы.

Пример правильной session фикстуры для xdist:

import pytest
from filelock import FileLock

@pytest.fixture(scope="session")
def shared_resource(tmp_path_factory, worker_id):
    # Если запуск не параллельный, просто делаем setup
    if worker_id == "master":
        return setup_database()

    # Получаем путь к временной папке для блокировки
    root_tmp_dir = tmp_path_factory.getbasetemp().parent
    fn = root_tmp_dir / "db.lock"

    # Блокируем файл: первый воркер выполнит код, остальные подождут
    with FileLock(str(fn)):
        # Проверяем, не создана ли уже база другим воркером
        if not check_db_exists():
            setup_database()

    return connect_to_db()

Часть 2: Анатомия плагинов pytest

Pytest построен на системе плагинов. Даже стандартные функции (например, assert или сбор тестов) реализованы как внутренние плагины. Это значит, что вы можете переопределить или расширить практически любое поведение фреймворка.

Что такое Hook (Хук)?

Хук — это точка в коде pytest, куда вы можете «вклиниться» со своей функцией. Все хуки начинаются с префикса pytest_.

Основные этапы жизни pytest и их хуки:

Bootstrap (Загрузка): pytest_load_initial_conftests, pytest_cmdline_main.
Configuration (Настройка): pytest_addoption, pytest_configure.
Collection (Сбор тестов): pytest_collection_modifyitems.
Run (Запуск): pytest_runtest_setup, pytest_runtest_call, pytest_runtest_teardown.
Reporting (Отчеты): pytest_runtest_logreport, pytest_sessionfinish.

Где писать плагины?

conftest.py: Для локальных плагинов, специфичных для конкретного проекта.
Отдельный пакет: Для переиспользования кода между разными проектами (публикуется на PyPI или устанавливается через git).

Практика: Пишем свои плагины

Давайте реализуем три полезных сценария, которые часто встречаются в реальной работе.

Сценарий 1: Добавление CLI-параметра (pytest_addoption)

Задача: Мы хотим запускать тесты на разных окружениях (dev, stage, prod) передавая флаг --env.

В файле conftest.py:

import pytest

def pytest_addoption(parser):
    parser.addoption(
        "--env",
        action="store",
        default="dev",
        help="Окружение для запуска тестов: dev, stage или prod"
    )

@pytest.fixture(scope="session")
def env_config(request):
    env_name = request.config.getoption("--env")
    # Здесь могла бы быть загрузка конфига из YAML
    return {"env": env_name, "url": f"https://{env_name}.example.com"}

def test_environment(env_config):
    print(f"Testing on {env_config['url']}")

Запуск:

pytest -s --env=prod

Сценарий 2: Пропуск медленных тестов (pytest_collection_modifyitems)

Задача: У нас есть тесты, помеченные маркером @pytest.mark.slow. Мы хотим запускать их только если передан специальный флаг --run-slow, иначе пропускать.

В файле conftest.py:

def pytest_addoption(parser):
    parser.addoption(
        "--run-slow", action="store_true", default=False, help="Запустить медленные тесты"
    )

def pytest_configure(config):
    # Регистрируем маркер, чтобы не было warning
    config.addinivalue_line("markers", "slow: mark test as slow to run")

def pytest_collection_modifyitems(config, items):
    # Если флаг передан, ничего не делаем (запускаем всё)
    if config.getoption("--run-slow"):
        return

    skip_slow = pytest.mark.skip(reason="нужен флаг --run-slow для запуска")

    for item in items:
        if "slow" in item.keywords:
            item.add_marker(skip_slow)

Теперь pytest пропустит медленные тесты, а pytest --run-slow запустит их.

Сценарий 3: Автоматическое добавление user-agent в отчет

Задача: Добавить в отчет (например, в заголовок консоли) информацию о версии тестируемого приложения.

def pytest_report_header(config):
    return "Project Version: 1.2.3 | Branch: feature/login"

Упаковка плагина

Если вы хотите использовать свой плагин в 10 разных микросервисах, копировать conftest.py — плохая идея. Лучше создать устанавливаемый пакет.

Структура папок:

pytest-myplugin/
├── pyproject.toml
└── pytest_myplugin.py

Содержимое pytest_myplugin.py — это просто код ваших хуков.

Содержимое pyproject.toml:

[build-system]
requires = ["setuptools>=61.0"]
build-backend = "setuptools.build_meta"

[project]
name = "pytest-myplugin"
version = "0.1.0"
description = "Мой крутой плагин"
entry-points = {"pytest11" = ["myplugin = pytest_myplugin"]}

Ключевая магия здесь — entry-points. Группа pytest11 говорит pytest'у: «Эй, посмотри в модуль pytest_myplugin, там есть хуки».

Установка:

pip install ./pytest-myplugin

Полезные ресурсы

Домашнее задание

Контекст: Вы работаете над проектом из предыдущих модулей (API + UI тесты). Тесты стали занимать слишком много времени.

Задача 1: Параллелизация

Установите pytest-xdist.
Запустите тесты с флагом -n auto.
Если какие-то тесты упали (из-за базы данных или файлов), исправьте их, используя фикстуры с уникальными данными (Faker) или временные директории (tmp_path), чтобы тесты не мешали друг другу.
Замерьте время выполнения с параллелизацией и без. Добавьте результаты в README.md.

Задача 2: Кастомный CLI-флаг

В conftest.py реализуйте хук pytest_addoption, добавляющий флаг --browser-mobile.
Напишите фикстуру, которая проверяет этот флаг. Если он True, то в настройках Playwright/Selenium устанавливается viewport (размер окна) как у iPhone 12 (390x844).
Напишите UI-тест, который проверяет наличие «гамбургер-меню» (оно появляется только на мобильных).

Задача 3: Динамический пропуск

Реализуйте логику в pytest_collection_modifyitems: если тесты запускаются на ОС Windows (проверка через sys.platform), то пропускать все тесты с маркером @pytest.mark.linux_only.

Критерии приемки:

Тесты проходят стабильно в 2+ потока.
Флаг --browser-mobile реально меняет размер окна браузера.
Код плагинов находится в conftest.py.

Типичные ошибки

Глобальные переменные: Использование списка users = [] на уровне модуля для хранения созданных юзеров. В xdist каждый процесс получит свою копию списка, и вы не сможете их синхронизировать.
Отсутствие атомарности: Тест А создает файл config.json, Тест Б его читает. В параллельном режиме Тест Б может запуститься раньше, чем Тест А закончит запись.
Принты в хуках: Использование print() внутри хуков настройки может не сработать или вывестись в неожиданном месте, так как pytest перехватывает stdout. Используйте logging.

В следующем, заключительном модуле курса, мы разберем сложные сценарии: тестирование WebSocket, OAuth авторизацию и работу с базами данных напрямую.

Сложные сценарии: базы данных, OAuth и вебсокеты

Добро пожаловать на десятую неделю курса «Автоматизированное тестирование на Python». Мы уже построили надежный фундамент: умеем писать UI и API тесты, запускать их в Docker и CI/CD. Но реальный мир Enterprise-разработки сложнее, чем тестирование статичных страниц.

Что отличает Senior QA Automation инженера от Junior? Умение работать с «черным ящиком» изнутри. Senior не просто кликает по кнопкам, он подготавливает состояние системы через базу данных, обходит сложные механизмы авторизации (OAuth) и умеет тестировать асинхронные интерфейсы реального времени (WebSockets).

В этом модуле мы разберем три «страшных» зверя, которых боятся новички, и научимся их приручать.

Цель модуля

К концу этой недели вы будете уметь:

Подключаться к SQL-базам данных (PostgreSQL/MySQL) напрямую из тестов для подготовки и проверки данных.
Использовать SQLAlchemy для удобной работы с БД в Python.
Понимать поток OAuth 2.0 и авторизовываться в тестах программно, минуя UI.
Тестировать WebSockets с использованием асинхронности (async/await).

Часть 1: Работа с Базой Данных (SQLAlchemy)

Теория: Зачем тестам доступ к БД?

В пирамиде тестирования мы часто говорим об изоляции. Но E2E и интеграционные тесты требуют данных. Есть два пути:

Через UI/API: Создать пользователя через POST-запрос, потом проверить его создание GET-запросом. Это медленно и ненадежно (если API создания сломано, тест проверки тоже упадет).
Через БД: Напрямую вставить запись в таблицу users перед тестом и проверить запись в таблице orders после теста. Это быстро, надежно и дает полный контроль над состоянием.

Для работы с БД в Python стандартом является библиотека SQLAlchemy. Она позволяет работать с базой как через «сырой» SQL, так и через ORM (Object-Relational Mapping), где таблицы представлены в виде классов Python.

Практика: Настройка фикстуры БД

Установим библиотеку:

pip install sqlalchemy psycopg2-binary

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

В файле conftest.py:

import pytest
from sqlalchemy import create_engine, text

# Строка подключения: тип_бд://юзер:пароль@хост:порт/имя_бд
DB_URL = "postgresql://user:password@localhost:5432/test_db"

@pytest.fixture(scope="session")
def db_engine():
    # Создаем движок (engine) - точку входа в БД
    engine = create_engine(DB_URL)
    yield engine
    engine.dispose()

@pytest.fixture(scope="function")
def db_connection(db_engine):
    # Для каждого теста открываем отдельное соединение
    connection = db_engine.connect()
    # Начинаем транзакцию
    transaction = connection.begin()

    yield connection

    # После теста откатываем транзакцию (ROLLBACK),
    # чтобы база осталась чистой!
    transaction.rollback()
    connection.close()

Важнейший паттерн: Обратите внимание на transaction.rollback(). Это позволяет не заботиться об удалении тестовых данных. Мы что-то записали, проверили, а потом «отменили» все изменения, как будто их и не было.

Пример теста с проверкой в БД

from sqlalchemy import text

def test_user_creation(api_client, db_connection):
    # 1. Arrange: Подготовка данных не нужна, база чистая
    payload = {"username": "test_user", "email": "test@example.com"}

    # 2. Act: Вызываем API создания пользователя
    response = api_client.post("/users", json=payload)
    assert response.status_code == 201
    user_id = response.json()["id"]

    # 3. Assert: Проверяем, что запись реально появилась в БД
    # Используем text() для сырого SQL запроса
    query = text("SELECT username, email FROM users WHERE id = :uid")
    result = db_connection.execute(query, {"uid": user_id}).fetchone()

    assert result is not None, "Пользователь не найден в БД"
    assert result.username == "test_user"
    assert result.email == "test@example.com"

Часть 2: Авторизация через OAuth 2.0

Теория: Почему UI-логин — это зло

Многие начинающие автоматизаторы в каждом тесте пишут:

Открыть страницу логина.
Ввести логин/пароль.
Нажать «Войти».
Ждать редиректа.

Если у вас 100 тестов, и логин занимает 5 секунд, вы тратите 8 минут просто на вход в систему. Более того, если вы используете Google или Facebook для входа (OAuth), капча или двухфакторная аутентификация (2FA) заблокируют вашего робота.

OAuth 2.0 — это протокол, позволяющий получить доступ к ресурсам без передачи пароля напрямую сервису. В тестах мы должны использовать программный логин (Programmatic Login).

Практика: Получение токена и инъекция

Вместо кликов мы отправляем один API-запрос к серверу авторизации, получаем токен и подкладываем его в браузер или API-клиент.

Пример фикстуры для получения токена (Keycloak/Auth0/Google):

import requests
import pytest

@pytest.fixture(scope="session")
def auth_token():
    url = "https://auth.example.com/realms/myrealm/protocol/openid-connect/token"
    payload = {
        "grant_type": "password",  # Или client_credentials
        "client_id": "my-test-client",
        "client_secret": "super-secret",
        "username": "test_admin",
        "password": "password123"
    }

    response = requests.post(url, data=payload)
    response.raise_for_status()
    return response.json()["access_token"]

Использование в API-тестах

def test_protected_resource(auth_token):
    headers = {"Authorization": f"Bearer {auth_token}"}
    response = requests.get("https://api.example.com/admin", headers=headers)
    assert response.status_code == 200

Использование в UI-тестах (Playwright)

В Playwright мы можем установить токен прямо в localStorage или cookies браузера, пропуская экран логина.

def test_dashboard_access(page, auth_token):
    # Открываем домен, чтобы можно было установить localStorage
    page.goto("https://app.example.com/login")

    # Инъекция токена через JavaScript
    page.evaluate(f"window.localStorage.setItem('access_token', '{auth_token}')")

    # Теперь переходим сразу в защищенную зону
    page.goto("https://app.example.com/dashboard")

    # Проверяем, что мы внутри
    assert page.locator("text=Welcome, Admin").is_visible()

Часть 3: Тестирование WebSockets

Теория: HTTP vs WebSocket

HTTP — это рация: нажал кнопку (Request), сказал, отпустил, ждешь ответа (Response). Связь прерывается. WebSocket — это телефонный звонок: соединение установлено постоянно, обе стороны могут говорить и слушать одновременно в любой момент.

Тестирование вебсокетов требует асинхронного подхода, так как мы не знаем, когда именно сервер пришлет сообщение.

Практика: Библиотека websockets

Для тестов нам понадобятся pytest-asyncio и библиотека websockets.

pip install websockets pytest-asyncio

В pytest.ini нужно разрешить асинхронные тесты:

[pytest]
asyncio_mode = auto

Пример теста эхо-сервера (сервер возвращает то, что ему отправили):

import pytest
import websockets
import json

@pytest.mark.asyncio
async def test_websocket_echo():
    uri = "ws://localhost:8000/ws/chat"

    # Устанавливаем соединение
    async with websockets.connect(uri) as websocket:
        # 1. Отправляем сообщение
        payload = {"message": "Hello, World!", "user_id": 1}
        await websocket.send(json.dumps(payload))

        # 2. Ждем ответа (с таймаутом, чтобы тест не завис навечно)
        # wait_for - важная часть, иначе тест может висеть бесконечно
        response = await websocket.recv()

        data = json.loads(response)
        assert data["message"] == "Hello, World!"

Сложный сценарий: Broadcast (Чат)

Как проверить, что сообщение от Юзера А пришло Юзеру Б?

@pytest.mark.asyncio
async def test_chat_broadcast():
    uri = "ws://localhost:8000/chat"

    # Подключаем двух клиентов
    async with websockets.connect(uri) as socket_a, \
               websockets.connect(uri) as socket_b:

        # Юзер А пишет сообщение
        await socket_a.send("Привет, Б!")

        # Юзер Б должен его получить
        message_b = await socket_b.recv()
        assert "Привет, Б!" in message_b

Домашнее задание

Контекст: Вы тестируете систему уведомлений. У вас есть доступ к БД (PostgreSQL), API авторизации и WebSocket-серверу уведомлений.

Задание:

Напишите фикстуру db_connection, которая подключается к БД (можно использовать SQLite для простоты или поднять Postgres в Docker).
Напишите фикстуру fake_token, которая генерирует JWT-токен (можно просто строку, если нет реального сервера).
Реализуйте интеграционный тест:
- Arrange: Вставьте в БД запись о новом пользователе через SQL.
- Act: Подключитесь к WebSocket от имени этого пользователя (передав токен в заголовках или URL).
- Act 2: Сделайте HTTP POST запрос к API /trigger-notification, который должен отправить уведомление этому пользователю.
- Assert: Проверьте через WebSocket, что уведомление пришло.

Критерии приемки:

Используется sqlalchemy.
Используется pytest-asyncio и websockets.
Тест атомарен: данные удаляются после выполнения (через rollback или фикстуру очистки).

Типичные ошибки

«Грязная» база: Тесты меняют данные в БД, но не убирают за собой. Следующий запуск падает, потому что «пользователь с таким email уже существует». Решение: используйте транзакции и rollback или удаляйте данные в teardown.
Хардкод токенов: Использование токена, который вы скопировали из браузера неделю назад. Токены протухают. Решение: получайте свежий токен в фикстуре перед запуском тестов.
Race Conditions в WebSocket: Вы пытаетесь прочитать сообщение (recv()) до того, как сервер успел его отправить. Решение: используйте механизмы повторных попыток (retries) или увеличенные таймауты, но не time.sleep().
Смешивание синхронного и асинхронного кода: Попытка вызвать requests.get внутри async def функции заблокирует весь цикл событий. Решение: используйте асинхронные HTTP-клиенты (например, httpx) внутри асинхронных тестов.

В следующем модуле мы займемся метриками и аналитикой: узнаем, что такое Code Coverage, как бороться с «мигающими» (flaky) тестами и как проходить собеседования на позицию Senior QA.

Метрики качества: Coverage.py и анализ flaky-тестов

Добро пожаловать на одиннадцатую неделю курса «Автоматизированное тестирование на Python». Мы уже научились писать тесты, запускать их в Docker и настроили CI/CD пайплайны. Казалось бы, работа сделана: тесты зеленые, деплой идет. Но как ответить на вопрос менеджера: «Насколько хорошо протестирован наш продукт?» или «Почему билд упал, а после перезапуска прошел?».

Отличие Senior-инженера от Junior не только в умении писать код, но и в умении измерять его эффективность и обеспечивать стабильность. Сегодня мы поговорим о метриках: как узнать, какой код мы забыли протестировать (Code Coverage), и как бороться с главным врагом автоматизации — нестабильными (flaky) тестами.

Цель модуля

К концу этой недели вы будете уметь:

Измерять покрытие кода тестами с помощью Coverage.py и плагина pytest-cov.
Понимать разницу между строковым покрытием (Line Coverage) и покрытием ветвлений (Branch Coverage).
Анализировать отчеты и исключать лишние файлы из статистики.
Выявлять и классифицировать flaky-тесты.
Использовать инструменты для отладки нестабильности: pytest-repeat, pytest-rerunfailures.

Часть 1: Покрытие кода (Code Coverage)

Теория: Что мы измеряем?

Code Coverage (покрытие кода) — это метрика, которая показывает, какая часть исходного кода была выполнена во время запуска тестов. Обычно она выражается в процентах.

Существует несколько уровней покрытия:

Line Coverage (Покрытие строк): Самая простая метрика. Если строка кода была выполнена хотя бы раз — она считается покрытой.
Branch Coverage (Покрытие ветвлений): Более строгая метрика. Она проверяет, были ли выполнены все возможные переходы в условиях if/else. Например, если у вас есть if x > 0, строковое покрытие засчитает тест с x=5, но покрытие ветвлений потребует еще и тест с x=-5, чтобы зайти в ветку else (даже если она неявная).

«100% покрытие кода не гарантирует отсутствие багов, но 0% покрытия гарантирует, что вы ничего не проверили». — Народная мудрость QA

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

Практика: Настройка Coverage.py

В экосистеме Python стандартом является библиотека coverage.py. Для удобной интеграции с pytest мы будем использовать плагин pytest-cov.

Установка:

pip install coverage pytest-cov

Базовый запуск

Допустим, у нас есть файл calculator.py и тесты к нему. Чтобы замерить покрытие, добавим флаг --cov:

pytest --cov=.

Вывод в консоли будет выглядеть примерно так:

Name             Stmts   Miss  Cover
------------------------------------
calculator.py       20      2    90%
test_calc.py        15      0   100%
------------------------------------
TOTAL               35      2    94%

Генерация HTML-отчета

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

pytest --cov=. --cov-report=html

После выполнения в папке проекта появится директория htmlcov. Откройте файл htmlcov/index.html в браузере. Вы увидите список файлов. Кликнув на файл, вы увидите исходный код, где красным цветом выделены строки, в которые тесты «не заходили».

Конфигурация (.coveragerc)

В реальных проектах мы не хотим считать покрытие для самих тестов, файлов миграций или конфигурационных файлов. Для этого создают файл настройки .coveragerc (или секцию в pyproject.toml / setup.cfg).

Создайте файл .coveragerc в корне проекта:

[run]
# Включаем покрытие ветвлений (Branch Coverage)
branch = True
# Источник кода (папка приложения)
source = app

[report]
# Не считать файлы тестов и миграций
omit =
    */tests/*
    */migrations/*
    venv/*

# Показывать строки, которые пропущены
show_missing = True

# Исключать из отчета строки с прагмой (комментарием)
exclude_lines =
    pragma: no cover
    def __repr__
    if __name__ == .__main__.:
    raise NotImplementedError

Теперь при запуске pytest --cov настройки подтянутся автоматически.

Branch Coverage в действии

Рассмотрим пример, почему важно включать branch = True.

def is_positive(number):
    if number > 0:
        return True
    # Здесь неявный return None

Тест:

def test_is_positive():
    assert is_positive(10) is True

Line Coverage: 100%. Все строки функции выполнены.
Branch Coverage: 50%. Мы проверили ветку True, но не проверили случай, когда условие ложно (number <= 0).

Включение branch = True в конфиге подсветит строку с if желтым цветом, указывая на неполное покрытие ветвлений.

Часть 2: Flaky-тесты (Мигающие тесты)

Теория: Кошмар автоматизатора

Flaky-тест (мигающий, хрупкий) — это тест, который при одних и тех же исходных данных (код не менялся) то проходит, то падает.

Почему это плохо?

Потеря доверия: Разработчики перестают реагировать на красные билды. «А, это опять тот тест упал, просто перезапусти». В итоге реальные баги пропускаются.
Замедление поставки: Приходится перезапускать пайплайны, теряя время (иногда часы).

Основные причины нестабильности

Race Conditions (Состояние гонки): Тест зависит от порядка выполнения или скорости работы системы (особенно в UI и Async тестах).
Тестовые данные: Использование одних и тех же данных в параллельных тестах или отсутствие очистки БД.
Внешние зависимости: API стороннего сервиса недоступен или отвечает медленно.
Время и даты: Тест падает только по ночам или в високосный год.
Порядок тестов: Тест А меняет глобальную переменную, а Тест Б ожидает её дефолтное значение.

Практика: Охота на Flaky-тесты

1. Выявление (pytest-repeat)

Если тест упал один раз, но проходит локально, попробуйте запустить его 100 раз подряд. Плагин pytest-repeat поможет в этом.

pip install pytest-repeat

Запуск конкретного теста 50 раз:

pytest tests/test_ui.py::test_login_button --count=50

Если он упадет хотя бы раз — поздравляю, вы поймали «флейк».

2. Изоляция (pytest-randomly)

Если тест падает только при запуске всего сьюта, но проходит изолированно, значит, он зависит от другого теста (загрязнение состояния). Плагин pytest-randomly перемешивает порядок выполнения тестов.

pip install pytest-randomly

Запустите тесты. Если упадет — посмотрите в лог, какой seed использовался, и вы сможете воспроизвести этот порядок снова:

pytest --randomly-seed=1234

3. Лечение симптомов (pytest-rerunfailures)

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

pip install pytest-rerunfailures

В pytest.ini:

[pytest]
addopts = --reruns 2 --reruns-delay 1

Это означает: «Если тест упал, подожди 1 секунду и попробуй еще раз. И так до 2 раз». Если с 3-й попытки прошел — тест помечается как PASSED (но в логах будет видно, что были ретраи).

Внимание: Не используйте это для Unit-тестов! Юнит-тесты должны быть железобетонно стабильными. Ретраи — это «пластырь» для UI/E2E.

Часть 3: Анализ результатов

Senior QA не просто смотрит на «зеленый» Jenkins. Он анализирует тренды.

Allure History

Если вы настроили Allure (как в модуле 6), используйте вкладку Trend. Если вы видите, что график длительности тестов ползет вверх, или количество broken тестов растет — это сигнал к рефакторингу.

Code Coverage как Quality Gate

В CI/CD можно настроить порог покрытия. Если PR снижает покрытие ниже 80% — билд падает.

Пример для GitHub Actions:

- name: Run tests with coverage
  run: pytest --cov=app --cov-fail-under=80

Флаг --cov-fail-under=80 заставит pytest вернуть код ошибки, если покрытие меньше 80%.

Полезные ресурсы

Домашнее задание

Контекст: Вы работаете над проектом интернет-магазина. У вас есть набор тестов, но вы не знаете, насколько они эффективны.

Задача 1: Настройка Coverage

Установите pytest-cov.
Создайте файл .coveragerc, исключив из отчета папку tests/ и любые файлы __init__.py.
Запустите тесты с генерацией HTML-отчета.
Найдите в коде функцию (или ветку if/else), которая не покрыта тестами (красная зона).
Напишите тест, который закрывает эту «дыру».

Задача 2: Детектив Flaky-теста Создайте файл test_flaky.py с заведомо нестабильным тестом:

import random
import pytest

def test_sometimes_fails():
    # Эмуляция сетевой ошибки с вероятностью 20%
    if random.random() < 0.2:
        raise ConnectionError("Network glitch")
    assert True

Запустите этот тест 50 раз с помощью pytest-repeat и убедитесь, что он падает.
Настройте pytest-rerunfailures так, чтобы тест проходил (зеленый статус), несмотря на сбои.
Добавьте маркер @pytest.mark.flaky(reruns=5) к этому тесту, чтобы переопределить глобальные настройки.

Критерии приемки:

HTML-отчет генерируется и открывается.
Процент покрытия вырос после добавления нового теста.
Нестабильный тест проходит в CI благодаря ретраям.

Типичные ошибки новичков

Гонка за 100%: Пытаться покрыть тестами каждую строчку, включая print() или тривиальные геттеры. Это трата времени. Ориентируйтесь на 80-90% для бизнес-логики.
Игнорирование .coveragerc: В отчет попадают библиотеки из venv или сами тесты, искажая статистику.
time.sleep() как решение: Если тест падает из-за скорости, новички ставят sleep(5). Это делает тесты медленными. Используйте явные ожидания (Waiters) или ретраи.
Ретраи для всего: Включение автоматического перезапуска для всех тестов скрывает реальные баги в коде приложения. Используйте их точечно.

Финал: архитектура фреймворка, портфолио и собеседование

Поздравляем! Вы прошли долгий путь длиной в 12 недель. Вы начали с простых утверждений assert, а закончили настройкой CI/CD пайплайнов и контейнеризацией. Вы больше не новичок, который пишет скрипты «на коленке». Вы обладаете инструментарием инженера по автоматизации.

Однако знание инструментов — это только половина успеха. Вторая половина — умение объединить их в единую, масштабируемую систему (фреймворк) и способность продать свои навыки работодателю.

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

Архитектура тестового фреймворка

Чем отличается набор скриптов от фреймворка? Скрипты решают сиюминутные задачи. Фреймворк создает структуру, которая позволяет добавлять новые тесты быстро, дешево и без дублирования кода. Хороший фреймворк похож на конструктор LEGO: у вас есть стандартные блоки, из которых вы собираете сценарии.

Основные слои

Config Layer (Конфигурация): Никакого хардкода. URL стендов, логины, пароли и таймауты должны лежать в переменных окружения (.env) или файлах конфигурации. Используйте библиотеку pydantic для валидации настроек.
Core / Client Layer (Ядро): Обертки над библиотеками. Если вы используете requests, создайте базовый класс BaseClient, который умеет логировать все запросы и ответы, автоматически подставлять базовый URL и обрабатывать таймауты.
Domain Layer (Бизнес-логика): Здесь живут Page Objects (для UI) и API Steps (для бэкенда). Тест не должен знать, какой локатор у кнопки «Купить». Тест должен вызывать метод cart_page.click_buy().
Test Layer (Тесты): Сами функции с префиксом test_. Они должны быть декларативными. Идеальный тест читается как сценарий на английском языке, без технических деталей реализации.

Пример структуры проекта

Вот как должен выглядеть ваш итоговый проект:

my_framework/
├── .github/              # CI/CD workflows
├── config/               # Настройки (pydantic models)
├── core/                 # Базовые классы (API client, WebDriver)
├── pages/                # Page Objects
├── services/             # API обертки
├── tests/                # Сами тесты
│   ├── api/
│   ├── ui/
│   └── conftest.py       # Фикстуры
├── utils/                # Генераторы данных (Faker), хелперы
├── .env.template         # Шаблон переменных окружения
├── .gitignore
├── docker-compose.yml
├── Dockerfile
├── pytest.ini
├── README.md             # Лицо вашего проекта
└── requirements.txt

Итоговые проекты курса

Чтобы закрепить знания и наполнить портфолио, вам нужно реализовать два проекта. Это ваша дипломная работа.

Проект 1: E2E тестирование демо-магазина (UI + API)

Цель: Продемонстрировать умение работать с гибридным тестированием. Объект: Любой демо-сайт (например, SauceDemo, OpenCart или PetStore).

Требования:

UI: Реализовать паттерн Page Object Model. Покрыть сценарии: логин, добавление в корзину, оформление заказа.
API: Если у сайта есть API, использовать его для подготовки данных (например, создать пользователя через API перед UI-тестом логина).
Данные: Использовать Faker для генерации email и адресов.
Отчеты: Интеграция с Allure (скриншоты при падении).

Проект 2: Инфраструктура для публичного API

Цель: Показать навыки DevOps и архитектуры. Объект: GitHub API, Trello API или любой публичный сервис.

Требования:

Docker: Тесты должны запускаться внутри контейнера.
CI/CD: Настроить GitHub Actions. Пайплайн должен запускаться на Pull Request, прогонять тесты и сохранять Allure-отчет как артефакт.
Notifications: (Опционально) Отправка результатов в Telegram/Slack.

Портфолио: GitHub как ваше резюме

Рекрутеры и техлиды смотрят код. Пустой GitHub — это красный флаг для Junior-специалиста. Но и GitHub, заваленный мусором («hello world», «test1»), не лучше.

Правила идеального репозитория

README.md — это король. Никто не будет читать ваш код, если не поймет, что он делает. В README.md должно быть:
- Заголовок: Что это за проект.
- Стек технологий: Python, Pytest, Playwright, Docker, Allure (используйте бейджи).
- Как запустить: Пошаговая инструкция (git clone -> pip install -> pytest).
- Примеры отчетов: Скриншот или ссылка на Allure.
Чистота кода. Используйте линтеры (flake8, black). Соблюдайте PEP8. Удалите закомментированный код и лишние принты.
История коммитов. Плохо: Update file, Fix, Fix 2. Хорошо: Add login page object, Refactor api client, Setup CI pipeline.
.gitignore обязателен. В репозитории не должно быть папок .venv, __pycache__, .idea или файлов с реальными паролями (.env).

Подготовка к собеседованию

Собеседование на QA Automation обычно состоит из трех частей: теория, задачи на кодинг и вопросы по инструментам.

Топ вопросов по Python

Типы данных: Изменяемые и неизменяемые. В чем разница между list и tuple, и почему ключом словаря может быть только неизменяемый тип?
ООП: Три кита (Инкапсуляция, Наследование, Полиморфизм) на примерах из автоматизации (например, BasePage).
Декораторы: Как работают, зачем нужны (пример: @pytest.fixture, @allure.step).
Генераторы и итераторы: В чем отличие yield от return? (Критично для понимания фикстур).

Топ вопросов по тестированию и инструментам

Pytest:
- Что такое фикстуры и какие у них есть scope?
- Как передать параметры в тест (parametrize)?
- Как запустить тесты параллельно?
Selenium / Playwright:
- Что такое неявные (implicit) и явные (explicit) ожидания? Почему time.sleep — это плохо?
- Как работает Page Object Model?
- Как обработать StaleElementReferenceException?
API:
- Разница между POST и PUT.
- Коды ответов (2xx, 3xx, 4xx, 5xx).
Git & CI/CD:
- Что такое Merge Request?
- Зачем нужен Docker в тестах?

Live Coding (Задачи на код)

Вас попросят написать код в реальном времени. Обычно это алгоритмические задачи легкого уровня или задачи на работу со строками/списками.

Задача: Написать функцию, которая проверяет, является ли строка палиндромом.
Задача: Найти уникальные элементы в списке.
Задача: Написать простейший клиент для API (GET запрос и проверка JSON).

«Не молчите во время лайв-кодинга. Рассуждайте вслух. Интервьюеру важнее понять ход ваших мыслей, чем увидеть идеально работающий код с первой попытки».

План обучения: 3 месяца (Сводная таблица)

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

Неделя	Темы	Часы (Теория / Практика)	Ключевые задачи	Ресурсы
1	Основы тестирования<br>Пирамида, STLC, виды тестов.	2 / 4	Написание тест-кейсов. Ручное тестирование формы.	ISTQB Glossary
2	Погружение в pytest<br>Asserts, fixtures, parametrize, marks.	3 / 7	Рефакторинг тестов с фикстурами. Параметризация калькулятора.	Pytest Docs
3	API-тестирование<br>Requests, REST, JSON Schema, Mocking.	3 / 8	CRUD тесты для PetStore. Валидация схем.	Requests Docs
4	UI-тестирование<br>Playwright, Locators, POM.	4 / 10	Автоматизация логина и корзины. Реализация Page Objects.	Playwright Python
5	Тестовые данные<br>Faker, JSON/YAML, Data Driven Testing.	2 / 5	Генератор пользователей. Вынос конфигов в YAML.	Faker Docs
6	Инфраструктура<br>Pytest.ini, Logging, Allure.	2 / 5	Настройка красивых отчетов. Логирование шагов.	Allure Docs
7	CI/CD<br>GitHub Actions, Workflows.	3 / 6	Пайплайн для запуска тестов по пушу. Артефакты.	GitHub Actions
8	Контейнеризация<br>Docker, Dockerfile, Compose.	3 / 7	Упаковка тестов в образ. Запуск через Compose.	Docker Get Started
9	Продвинутый pytest<br>Xdist (параллельность), Hooks, Plugins.	2 / 5	Ускорение тестов в 4 потока. Написание плагина.	Pytest-xdist
10	Сложные сценарии<br>DB (SQLAlchemy), OAuth, WebSockets.	3 / 6	Тест с проверкой в БД. Авторизация через API.	SQLAlchemy
11	Метрики и качество<br>Coverage, Flaky tests.	2 / 4	Анализ покрытия кода. Лечение мигающих тестов.	Coverage.py
12	Финал<br>Архитектура, Портфолио, Собеседование.	2 / 10	Итоговый проект. Оформление GitHub.

Заключение

Путь от Junior до Senior — это не спринт, а марафон. Этот курс дал вам карту и набор инструментов. Теперь всё зависит от вашей практики. Не бойтесь сложных задач, читайте чужой код, вносите вклад в Open Source и постоянно учитесь.

Удачи на собеседованиях! Ваш код будет чистым, а тесты — зелеными.