Factory і фабрики даних

Фабрика тестових даних

Factory інкапсулює створення об'єкта. У TypeScript-тестах найпопулярніший варіант це проста функція з дефолтами і Partial override:

export function createCard(overrides: Partial<Card> = {}): Card {
  return {
    number: '4111111111111111',
    holder: 'TEST USER',
    expiry: '12/30',
    cvv: '123',
    ...overrides,
  };
}

const expired = createCard({ expiry: '01/20' });

Це коротше за Builder і повністю типізовано: TypeScript не дасть передати поле, якого немає в Card.

Друга популярна форма це фабрика, яка не лише будує об'єкт, а й створює сутність у системі через API:

export async function createAccountViaApi(
  request: APIRequestContext,
  overrides: Partial<NewAccount> = {},
) {
  const res = await request.post('/api/accounts', {
    data: { currency: 'EUR', ...overrides },
  });
  expect(res.ok()).toBeTruthy();
  return (await res.json()) as Account;
}

Таку функцію зручно загорнути у фікстуру, щоб додати cleanup після use.

Нюанс зі spread: overrides з полем undefined перезапише дефолт на undefined. Для вкладених об'єктів spread поверхневий, тому вкладені override треба мержити окремо.

Factory vs Builder і фабрика Page Objects

Чим відрізняються:

На практиці їх поєднують: Builder може всередині використовувати фабрику дефолтів.

Ще одне застосування це фабрика Page Objects, щоб не писати new у кожному тесті. Наприклад, клас App з геттерами loginPage, paymentsPage. Але в Playwright цю роль зазвичай краще виконують фікстури: вони ліниві і вже інтегровані з раннером. Окрема фабрика сторінок має сенс, коли сторінки треба створювати динамічно всередині тесту (наприклад, після відкриття нової вкладки отримали новий page).

Коли фабрика НЕ потрібна: якщо об'єкт використовується в одному тесті і його поля і є суттю перевірки. Тоді явний літерал у тесті читається краще (DAMP).

Типова помилка: фабрика, яка повертає той самий об'єкт-константу, а тест його мутує. Наступний тест отримує зіпсовані дані. Фабрика завжди має повертати новий об'єкт.