Тестовые данные и фикстуры

Половина нестабильных тестов — это проблемы с данными: два параллельных теста правят одну запись, тест зависит от того, что оставил предыдущий, на стенде кто-то удалил нужную страницу. Агент усугубляет это, если ему не объяснить правила: он охотно захардкодит test@test.ru в двадцати местах. Разберём, как навести порядок и поручить агенту рутину.

Три правила для данных

Запишите их в AGENTS.md — агент будет следовать им в каждом новом тесте:

### Тестовые данные

- Каждый тест создаёт свои данные и не зависит от других тестов и порядка запуска.
- Уникальность: в имена и email добавляется идентификатор воркера и время,
  домен — example.test.
- Созданное в тесте удаляется в его же фикстуре после выполнения.
- Общие справочные данные — только из сидов проекта; править их в тесте запрещено.
- Реальные персональные данные (дампы прода, выгрузки CRM) в тестах и в чате с агентом запрещены.

Домен .test зарезервирован для тестирования и никогда не станет настоящим — письмо на такой адрес не уйдёт живому человеку, даже если отправка где-то не отключена.

Фикстуры Playwright

Фикстура в Playwright — функция, которая готовит данные до теста и убирает после. Попросите агента вынести повторяющуюся подготовку из спеков в фикстуру:

import { test as base, expect } from '@playwright/test';

type Lead = { name: string; email: string; phone: string };

export const test = base.extend<{ lead: Lead }>({
  lead: async ({ request }, use, testInfo) => {
    const id = `${testInfo.workerIndex}-${Date.now()}`;
    const lead: Lead = {
      name: `Тест ${id}`,
      email: `qa+${id}@example.test`,
      phone: '+79990000000',
    };

    await use(lead);

    // уборка: тестовый эндпоинт доступен только на локальном стенде
    await request.delete(`/test-api/leads?email=${encodeURIComponent(lead.email)}`);
  },
});

export { expect };

Спек импортирует test из фикстуры, а не из @playwright/test, и получает готовые данные:

import { test, expect } from './fixtures/lead';

test('заявка с уникальными данными попадает в список', async ({ page, lead }) => {
  await page.goto('/contacts');
  await page.getByLabel('Имя').fill(lead.name);
  await page.getByLabel('Email').fill(lead.email);
  await page.getByRole('button', { name: 'Отправить' }).click();
  await expect(page.getByText('Спасибо, заявка отправлена')).toBeVisible();
});

Эндпоинт уборки в примере условный: в вашем проекте это может быть служебный маршрут, доступный только при локальном окружении, команда artisan или прямой запрос в тестовую базу. Важно, чтобы способ был один и описан в AGENTS.md, иначе агент изобретёт новый в каждом тесте.

Авторизация без повторного логина

Если тесты работают под пользователем, логиниться в каждом тесте долго и нестабильно. В Playwright принято выполнять вход один раз в отдельном проекте настройки и сохранять состояние браузера через storageState, а остальные проекты подключают его через dependencies. Попросите агента настроить это по документации Playwright и проверить, что тесты под разными ролями используют разные файлы состояния. Файлы состояния — в .gitignore: в них лежат куки сессии.

Учётные данные тестовых пользователей берутся из сидов или переменных окружения стенда — не из чата с агентом и не из личных аккаунтов.

Сиды и фабрики на бэкенде

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

Найди в tests/ места, где модели создаются вручную с заполнением всех
полей. Предложи фабрики для этих моделей с минимальными валидными
значениями и состояниями (например, «опубликованная», «черновик»).
Перепиши два самых длинных теста на фабрики. Поведение тестов не меняй;
прогони их до и после и приложи оба вывода.

Прогон «до и после» — способ убедиться, что рефакторинг тестов не поменял, что они проверяют.

Генерация наборов данных

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

Сгенерируй JSON-набор для проверки поля «Имя»: по 3 значения на каждый
класс — валидные, пустые, на границе длины 100 и 101, со спецсимволами,
с эмодзи, с HTML-тегами (как текст). У каждого значения: value, class,
expected ("accept" | "reject"), причина.

Такой набор можно подключить к параметризованному тесту, и при ревью видно, почему каждое значение там оказалось.

Персональные данные

Самая опасная ошибка с данными — дать агенту реальные. Дамп продовой базы, выгрузка из CRM или список клиентов в промпте — это передача персональных данных во внешний сервис. Правило курса простое: агенту — только синтетика и сиды. Если для воспроизведения бага нужна структура реальных данных, сначала обезличьте их скриптом. Скрипт обезличивания агент напишет быстро, но проверяете его вы: просмотрите результат на предмет оставшихся email, телефонов и имён в свободных текстовых полях — комментариях, адресах, заметках менеджеров.