Fuente
QA Co-pilot | ️ Битва підходів: Junior vs. QA Architect (Як ми готуємо тестові дані)...
30 Vistas/Alcance
2026-05-08 12:41
Mensaje №288
⚔️ Битва підходів: Junior vs. QA Architect (Як ми готуємо тестові дані)Сьогодні в нашій "Битві підходів" розбираємо найдорожчий і найповільніший етап будь-якого E2E тестування — підготовку тестових даних (Data Setup або Preconditions). ☕️Уявімо задачу: нам треба протестувати видалення користувача з таблиці.❌ Підхід Junior-автоматизатора (Через UI)test('Повинен видаляти користувача', async ({ page }) => { // 1. Спочатку створюємо юзера через інтерфейс (марнуємо 10 секунд) await page.locator('#add-btn').click(); await page.locator('#name').fill('Test QA'); await page.locator('#save').click(); await expect(page.locator('.toast')).toHaveText('Створено!'); // 2. І тільки тепер починаємо сам тест на ВИДАЛЕННЯ await page.locator('#delete-btn-Test-QA').click(); await expect(page.locator('.row')).not.toContainText('Test QA');});
Чому це архітектурна катастрофа: По-перше, ви спалюєте гроші компанії на інфраструктуру. Цей тест йтиме 15 секунд замість трьох.По-друге, ви створюєте Каскадні падіння (Cascading Failures). Якщо завтра фронтендер випадково зламає форму створення користувача, у вас впаде тест на видалення! Ваш репорт покаже 50 червоних тестів, хоча насправді баг тільки в одному місці.
✅ Підхід QA Architect (Через API)test('Повинен видаляти користувача', async ({ page, request }) => { // 1. Б'ємо напряму в бекенд. Створюємо юзера за 50 мілісекунд const res = await request.post('/api/users', { data: { name: 'Test QA' } }); const user = await res.json(); // 2. Ізольовано тестуємо ТІЛЬКИ видалення через UI await page.goto(`/users/${user.id}`); await page.locator(`#delete-btn-${user.id}`).click(); await expect(page.locator('.row')).not.toContainText('Test QA');});
Чому це шедевр:Тест атомарний. Він перевіряє рівно одну фічу — видалення. Підготовка даних займає мілісекунди. Якщо форма створення зламана, цей тест все одно пройде і доведе, що механізм видалення працює ідеально.
Золоте правило: Інтерфейс користувача (UI) створений для тестування самого UI. Використовувати UI для підготовки даних (Preconditions) — це як забивати цвяхи мікроскопом. Для цього є API та прямі запити до бази даних.А як у вас на проєкті генеруються дані перед E2E тестами? 👇🔥 — Тільки API / База даних! Наші тести летять як ракета.👀 — Робимо через UI... Так, тести йдуть по 2 години, але в нас "повна імітація юзера"!🤬 — У нас взагалі один юзер [email protected] на всю команду, хто перший зайшов, той і тестує!