QA Co-pilot

💩 Код з душком: "Магічні числа" в API-тестах (або Чому ваші пайплайни падають по понеділках)

Привіт, екіпаж! П'ятниця — традиційний час вивітрювати "смердючий" код з репозиторіїв. Ми вже розбиралися з крихкими UI-локаторами та залежними тестами. Сьогодні ліземо під капот і препаруємо найпопулярніший гріх при тестуванні бекенду. Говоримо про хардкод і статичні дані. ☕️

Знайдіть проблему в цьому тесті:

// ❌ Як пишуть "на швидку руку" (Антипатерн: Прив'язка до статичної БД)
test('Повинен успішно отримати профіль користувача', async ({ request }) => {
  // Звертаємось до конкретного ID, який хтось колись створив руками
  const response = await request.get('/api/users/42');
  const user = await response.json();

  expect(response.status()).toBe(200);
  expect(user.email).toBe('test-qa@example.com');
});

Чому цей код тхне:

Це класична бомба уповільненої дії. На вашій локальній машині цей тест буде зеленим. Але коли ви тестуєте сучасний бекенд (наприклад, написаний на NestJS у зв'язці з PostgreSQL), сутності створюються динамічно.

Щойно цей тест потрапить у CI/CD, де база даних піднімається з нуля в Docker-контейнері, або якщо інший розробник випадково видалить юзера з ID 42 — тест впаде з помилкою 404 Not Found. Ви будете витрачати години на дебаг "зламаного" бекенду, хоча насправді бекенд працює ідеально, просто тест зав'язаний на ілюзорні дані.

✅ Як це виглядає після код-рев'ю Senior-інженера:

Тест ніколи не повинен розраховувати на те, що в базі "вже щось є". Він має сам забезпечити себе даними, отримати динамічний ідентифікатор (UUID або автоінкремент) і працювати виключно з ним.

// 🚀 Ідеально чистий код (Динамічна генерація стану)
test('Повинен успішно отримати профіль користувача', async ({ request }) => {
  // 1. Arrange: Динамічно створюємо юзера з унікальним email
  const uniqueEmail = `qa-test-${Date.now()}@example.com`;
  const createRes = await request.post('/api/users', {
    data: { email: uniqueEmail, role: 'candidate' }
  });
  const newUser = await createRes.json();

  // 2. Act: Використовуємо динамічний ID, який щойно згенерувала БД
  const response = await request.get(`/api/users/${newUser.id}`);
  const fetchedUser = await response.json();

  // 3. Assert: Перевіряємо результат
  expect(response.status()).toBe(200);
  expect(fetchedUser.email).toBe(uniqueEmail);
});

Чому це шедевр:

Цей тест абсолютно автономний і куленепробивний. Ви можете запускати його в 100 потоків паралельно, на порожній чи заповненій базі — він ніколи не перетнеться з іншими тестами, бо щоразу генерує унікальні сутності і посилається тільки на них.

Золоте правило: Якщо у ваших API-тестах є захардкоджені ID (наприклад 100500, user-123), рано чи пізно цей тест зрадить вас у пайплайні. Генеруйте дані "на льоту".

А як у вас справи з тестовими даними? 👇
🔥 — Тільки динамічна генерація, мій фреймворк сам створює все необхідне!
👀 — Грішу хардкодом... У нас є спеціальний тестовий юзер, якого ми всі боїмося видалити.
🤯 — А що робити, якщо бекенд не має ендпоінту для створення юзера?!

❤1👍1

36 views08:47