Skip to main content

🔁 Итерация 3: параметризация тестов с @TestCase.each

Один из самых частых паттернов в автотестах — проверка одного сценария с разными данными.
Vitest умеет test.each(...), но наш DSL — тоже.

🧩 Цель​

  • Добавить @TestCase.each([...]) — для генерации множественных тестов
  • Автоматически передавать параметры в метод
  • Фиксировать значения в отчёте через allure.parameter

📦 Как выглядит​

@Feature('Авторизация')
class AuthTests {
  @TestCase.each([
    ['admin@example.com', 'admin123', 200],
    ['user@example.com', 'user123', 200],
    ['hacker@example.com', 'wrongpass', 401],
  ])('Логин для %s', async (email, password, expectedStatus) => {
    const res = await axios.post('/login', { email, password })
    expect(res.status).toBe(expectedStatus)
  })
}

✅ Что происходит:​

  • Генерируются 3 отдельных теста с названиями:
    • Логин для admin@example.com
    • ...
  • Аргументы email, password, expectedStatus передаются в метод
  • Allure фиксирует параметры:
    • param1 = admin@example.com
    • param2 = admin123
    • param3 = 200

🧠 Любое количество аргументов​

Метод получает столько аргументов, сколько указано в .each():

@TestCase.each([
  ['admin', '123', 'desktop', true],
  ['guest', 'qwerty', 'mobile', false]
])('Попытка входа: %s', async (login, pass, platform, expected) => {
  // все аргументы приходят как есть
})

DSL не ограничивает количество параметров — работает как (...args) => {}

📈 Выгода:​

  • Читаемость и лаконичность
  • Единая точка теста и данных
  • Allure отображает параметры и шаги для каждого случая
  • Работает с step() и attach()

🎯 Результат​

Теперь наш DSL поддерживает один из самых частых паттернов в тестировании.
В следующей итерации — @BeforeEachCase, хуки и re-use шагов.

💭 «Постойте… А чем это лучше обычного test.each?»​

Отличный вопрос.

Вы, скорее всего, сейчас думаете:

«Окей, я вижу @TestCase.each, красиво, декларативно…
Но ведь у Vitest уже есть test.each(...) — разве не то же самое?»

Разберём по полочкам.

🤜 test.each — это удобно. Но…​

Когда вы пишете так:

test.each([
  ['email1', 'pass1', 200],
  ['email2', 'pass2', 401],
])('Login for %s', ...)

— вы получаете быстрый, минималистичный тест.

Но что если вы хотите:

  • Подсветить фичу (@Feature('Авторизация'))
  • Повесить ID на тест (AS_ID, TMS, Issue)
  • Проставить severity или owner
  • Сделать структурированные шаги внутри отчёта
  • Приложить response JSON в Allure

Всё это вам придётся делать вручную, с кучей allure.label(...), allure.step(...) и allure.attachment(...).

🎯 А вот @TestCase.each — уже про сценарии​

@TestCase.each([
  ['admin@example.com', 'admin123', 200],
  ['user@example.com', 'user123', 200],
])('Логин для %s', { severity: 'critical' })
async login(email, password, expectedStatus) {
  ...
}

И вы получаете:

  • ✅ Один метод → несколько кейсов
  • ✅ Метки (severity, feature) — встроены
  • ✅ Название кейса — шаблонное
  • ✅ Параметры отображаются в Allure
  • ✅ Весь отчёт структурирован: шаги, вложения, параметры

📊 Сравнение​

Параметрtest.each(...)@TestCase.each(...)
Краткость✅✅
Структура отчёта❌✅
Метки, severity❌✅
Шаблон названия✅✅
Поддержка классов❌✅
Расширяемость⚠️ Ограничена✅ Управляемая
Интеграция с TestOps❌✅
💡 Модель мышленияФункцияТест-кейс

💡 Вывод​

Если вы просто хотите повторить тест 3 раза — test.each вас спасёт.
Но если вы описываете бизнес-сценарии, хотите качественные отчёты и масштабируемый DSL,
то @TestCase.each — это уже язык, а не просто удобная функция.
По сути, мы создаём структурированный тестовый фреймворк на базе Vitest, не конкурируя с ним, а надстраивая декларативный слой.