Принципи дизайну тестового коду: DRY, KISS, YAGNI, композиція

Що таке принцип DRY і чому «повторення» в ньому стосується не схожих рядків?

DRY (Don't Repeat Yourself) — вимога, щоб кожен елемент знання в системі мав одне авторитетне джерело. Ключове слово тут — знання, а не текст: принцип цілиться в дублювання рішення (бізнес-правила чи способу виконати дію), а не візуально однакових рядків. Небезпека справжнього дубля в тому, що одного дня його поправлять в одному місці й забудуть в іншому — і система стане суперечливою. У тестах хрестоматійний приклад — покрокова логіка логіну, розписана в десятках тестів: варто змінитися формі входу, і треба редагувати кожну копію. А от два фрагменти, які просто зараз схожі, але концептуально незалежні, дублем знання не є — об'єднувати їх не обов'язково.

Чому тестовий код інколи навмисно роблять DAMP, а не максимально DRY?

Бо тест — це ще й документація: його читають, щоб зрозуміти, що ми стверджуємо про систему. Принцип DAMP (Descriptive And Meaningful Phrases) ставить читабельність вище за мінімізацію рядків. Якщо гнатися за DRY і ховати суть перевірки під шар абстракцій, тест вироджується в набір викликів чорних скриньок: коли він падає, незрозуміло, що саме зламалось, без розкручування всього клубка. DAMP не заперечує DRY, а розставляє акценти — намір і асерції видно локально, прямо в тілі тесту. Невеликий дубль expect між сусідніми тестами тут прийнятна ціна за те, що тест читається як специфікація поведінки.

Де проходить межа: що виносити у спільне, а що лишати в тілі тесту?

Робоча евристика формулюється парою: DRY на механіку, DAMP на намір. Механіка — це як ми виконуємо дію: логін, підготовка даних, навігація; її виносять в одне джерело — хелпер, фікстуру або метод page object. Намір — це що ми перевіряємо: arrange-дані конкретного сценарію і всі expect; вони лишаються в тілі тесту, навіть ціною повторів між тестами. Тобто спільною стає рутина, а унікальним — твердження. Простий критерій, що межу проведено правильно: читаючи тест, ви розумієте, що він перевіряє, не відкриваючи інші файли.

Чому винесення expect у спільний хелпер — майже завжди помилка?

Тому що перевірка і є суттю тесту, а сховати її означає змусити читача довіряти назві функції замість того, щоб бачити саме твердження. Коли умовний assertHappyPath(page) падає, ви не знаєте, який конкретно expect усередині червоний, поки не відкриєте хелпер, — а це прямо суперечить ролі тесту як документації. Механіку дії ховати можна й треба, а суть перевірки — ні: вона має лишатися перед очима. Єдиний розумний виняток — тонкі доменні матчери, які роблять асерцію виразнішою, а не ховають її.

Що таке KISS і як він проявляється в автотестах?

KISS (Keep It Simple, Stupid) — вимога брати найпростіше рішення, яке розв'язує задачу, і не додавати складності без причини. У тестах це особливо гостро: складний тест не викликає довіри, бо коли він червоніє, першою підозрюють не продукт, а власну хитромудру логіку. Часто KISS зводиться до «довіряй інструменту» — якщо фреймворк уже вміє чекати, ретраїти асерцію чи ізолювати контекст, не переписуй це руками. Простіший тест водночас і надійніший, і зрозуміліший, і дешевший у підтримці.

Наведіть приклад порушення KISS у Playwright-тесті.

Найтиповіший — ручний polling там, де є web-first assertion. Замість циклу з waitForTimeout(500) і власним прапорцем, який чекає появи елемента, достатньо await expect(locator).toBeVisible(): воно саме перечікує й ретраїть до таймауту. Інші впізнавані симптоми: обгортка над expect, яка «покращує» повідомлення, а насправді ховає стек; регулярка на десять груп там, де вистачає toContainText; генерація даних циклом з розгалуженнями замість трьох явних рядків. Спільне в усіх випадках — рукотворна складність поверх того, що інструмент уже вміє сам.

Що таке YAGNI і чому передчасні абстракції в тестах дорожчі, ніж у продукті?

YAGNI (You Aren't Gonna Need It) — принцип з екстремального програмування: не будуй функціональність, поки вона реально не знадобилась. У тестовій автоматизації його порушують на старті, коли є десять тестів, а вже пишеться «універсальний фреймворк на виріст» — базові класи й фабрики драйверів під те, чого в проєкті немає. Ціна висока з двох причин. По-перше, за абстракцію ви платите підтримкою вже сьогодні, а окупність гіпотетична й у майбутньому, яке може не настати. По-друге — і це специфіка тестів — форму абстракції, витягнутої з одного-двох випадків, майже завжди вгадують неправильно: третій реальний кейс у неї не влізе, і доведеться або ламати її, або натягувати кейс на неї прапорцями.

Що таке «правило трьох» і навіщо воно?

Це емпіричне правило, яке підказує момент для узагальнення: перший раз просто пиши, другий — стерпи дубль і поміть його, і лише на третьому подібному випадку виноси спільне. Сенс у тому, що два приклади брешуть про вісь варіативності, а три вже показують її по-справжньому — видно, що насправді спільне, а що відрізняється. Це протиотрута і від передчасних абстракцій (винесли зарано — вгадали форму неправильно), і від сліпого DRY. Правило не догма, а нагадування зачекати з узагальненням, поки не набереться достатньо доказів.

У чому різниця між композицією (has-a) і успадкуванням (is-a)?

Успадкування — це відношення «є» (is-a): клас-нащадок є різновидом базового й дістає його поведінку через ланцюг предків. Композиція — відношення «має» (has-a): об'єкт збирає потрібну поведінку з окремих частин, які містить у собі. Канонічна порада «банди чотирьох» (Gang of Four) — надавати перевагу композиції об'єктів над успадкуванням класів. Практичний тест на вибір: якщо між класами справді відношення «є» і ланцюг неглибокий — успадкування доречне; якщо ви успадковуєте лише щоб перевикористати код, це насправді «має», натягнуте на «є».

Чому в тестовому коді композицію віддають перевагу особливо жорстко?

Тому що тести читають поодинці, а глибокі ієрархії роблять це неможливим. Спокуса виглядає невинно: спільне виносимо в BaseTest, від нього — BaseUiTest, далі — BaseAuthTest; кожен крок логічний, а через півроку маєш ланцюг на чотири рівні, у якому не відповіси на просте «звідки в цьому тесті взявся залогінений юзер». Композиція через фікстури й компоненти лишає це видимим: тест явно оголошує, що йому треба, і поведінка збирається локально. До того ж успадкування фіксує комбінацію під час написання класу, а фікстури дають зібрати рівно те, що потрібно конкретному тесту.

Що таке «крихкий базовий клас» (fragile base class)?

Це ситуація, коли зміна в базовому класі непередбачувано розходиться по всіх нащадках. Ви поправили beforeEach заради одного тесту — і впало п'ятдесят інших, бо вони мовчки залежали від старої поведінки. Проблема тим гостріша, чим глибший ланцюг і чим більше нащадків: базовий клас стає таким, що його страшно чіпати, а будь-яке редагування перетворюється на лотерею. Це один з головних аргументів проти глибоких ієрархій у тестах, де setup часто зашитий саме в базу.

Як фікстури Playwright реалізують композицію?

Фікстура (test.extend) віддає тесту рівно ті об'єкти, які він попросив у своїх параметрах, — у явному, читабельному вигляді. Замість того щоб бути нащадком якогось BaseAuthTest, тест має потрібні здатності: оголошуєш у сигнатурі cart — і фреймворк збирає для тебе кошик поверх залогіненої сторінки. Фікстури можуть залежати одна від одної (cart будується на authedPage, той — на page), тож поведінка компонується ланцюжком, але видимим і плоским, а не захованим у ієрархії предків. Це рідна для Playwright модель, і саме тому в ньому рідко потрібне успадкування тестових класів.

Успадкування в тестах не заборонене повністю — коли воно виправдане?

Коли між класами справді є відношення «є» і ланцюг неглибокий. Тонкий BaseComponent з полем page і спільним конструктором — законний один рівень: усі компоненти справді є компонентами. Правило не про повну заборону, а про глибину й мотив: погано, коли успадкування тягнуть заради перевикористання поведінки (це мала б бути композиція) або коли будують ланцюг на кілька поверхів. Один тонкий базовий рівень з чіткою семантикою «є» — нормально; ієрархія setup на чотири рівні — вже борг.

Як принцип композиції проявляється всередині page object?

Замість того щоб CheckoutPage успадковувала HeaderPage, вона містить компоненти: header, cart, paymentForm. Кожен компонент — окремий повторно вживаний клас зі своїми локаторами й діями, а сторінка складається з них. Це і є перехід від глибоких ієрархій сторінок до плоскої композиції компонентів: додати новий блок — означає додати поле, а не наростити ще один рівень extends. Вигода та сама, що й у тестах: локальна читабельність і відсутність крихкого базового класу.

На що дивитись на код-рев'ю тестового коду — і чим воно відрізняється від рев'ю продуктового?

Головне питання тут не «чи ефективно написано», а «чи зрозуміло, що і чому перевіряється, і чи не розвалиться це на першому редизайні». Практичний чек-лист: чи видно намір тесту без стрибків у хелпери (інакше треба повернути асерції в тіло); чи локатори прив'язані до data-testid, ролей і текстів, а не до крихких CSS-шляхів; чи немає waitForTimeout з магічним числом; чи тест незалежний, ізольований і прибирає за собою; чи не з'явився передчасний «універсальний» базовий клас; чи дані свіжі, а не хардкоджені id та дати. Корисна евристика: якщо для розуміння одного тесту доводиться відкрити більше двох-трьох файлів — абстракцій забагато.

«Виглядає як DRY, а насправді втрата читабельності» — поясніть цю пастку.

Це коли під гаслом «не повторюватись» у спільний хелпер виносять не механіку, а саму суть перевірки. Формально дубль прибрано, а фактично тест осліп: при падінні незрозуміло, який конкретно інваріант зламався, поки не розгорнеш хелпер. Причина плутанини в тому, що DRY стосується дублювання рішення (механіки дії), а не тверджень, які й мають бути перед очима. Лікування просте — повернути асерції в тіло тесту (DAMP), лишивши спільним тільки те, як виконується дія.

Два схожі шматки коду об'єднали в одну функцію — коли це помилка?

Коли вони схожі випадково, а не тому, що виражають одне рішення. Однаковий вигляд — не привід для DRY; привід — однакове знання. Якщо два фрагменти зараз збігаються, але концептуально незалежні, то щойно один зміниться, спільна функція обросте прапорцями на кшталт if (isPremium) й розгалуженнями — тобто перетвориться на два кейси, зшиті в один, який читати важче, ніж два явні шматки. Це хибне узагальнення. Тест на справжній дубль простий: спитати, чи змінюватимуться ці місця разом і з однієї причини.

CheckoutTest extends LoginTest — що тут не так?

Порушено семантику успадкування: checkout не є різновидом логіну, він ним користується. Це відношення «має», яке натягнули на «є» лише щоб не писати код входу двічі — класична пастка «успадкування заради перевикористання». Наслідки типові: логін зашитий посередині ієрархії, тож не можна зробити тест checkout без автологіну; будь-яка зміна в LoginTest б'є по всіх нащадках. Правильно винести логін у фікстуру чи хелпер — і тест checkout просто отримає залогінену сесію як здатність, а не успадкує її разом з усім рештою.

Три ситуації з рев'ю, де ці принципи перестають бути гаслами й стають конкретним рішенням на код: над-DRY тест, який осліп, і повернення його в DAMP; передчасна абстракція, розпізнана за «правилом трьох»; та розплутування ланцюга успадкування BaseTest у плоскі фікстури Playwright. Скрізь — що змінюємо і чому.

Кейс 1. Над-DRY тест: чому «нуль повторень» коштує читабельності

На рев'ю прилетів тест, який автор гордо стиснув до трьох рядків. Дублювання нема — і саме в цьому проблема.

// БУЛО: намір заховано в трьох хелперах
test('checkout premium', async ({ page }) => {
  await setupScenario(page, CONFIG.premium);
  await runPurchase(page, DATA.cartA);
  await assertHappyPath(page);        // ← що саме тут перевіряється?
});

Питання рев'ю: коли assertHappyPath почервоніє в CI, що ми дізнаємось? Нічого — доведеться відкрити хелпер, потім CONFIG.premium, потім DATA.cartA, щоб зібрати в голові, який інваріант зламався. Тест перестав бути документацією й став викликом трьох чорних скриньок. Повертаємо намір у тіло, лишаючи спільною тільки механіку входу:

// СТАЛО: механіка спільна, намір і асерції — локальні
test('преміум-користувач має безкоштовну доставку в кошику', async ({ page }) => {
  await loginAs(page, users.premium);          // ← механіка з хелпера, це ОК
  await page.goto('/cart');
  await cart.addItem('Мишка Logitech');

  await expect(cart.shippingLabel).toHaveText('Безкоштовна доставка');
  await expect(cart.total).toHaveText('₴1200');
});

Щоб рішення «виносити чи лишати» не було на око, корисно тримати в голові таку таблицю межі:

Що дивитися і чому:

• Спільний assert — майже завжди помилка. Механіку дії ховати можна, суть перевірки — ні: вона має бути перед очима, інакше падіння не діагностувати без розкручування клубка.
• Дубль двох expect між сусідніми тестами — не борг. Це читабельність. Стискати його в assertHappyPath — міняти діагностованість на ілюзію чистоти.
• Назва тесту теж документація. checkout premium не каже нічого; преміум-користувач має безкоштовну доставку — це вже інваріант, який видно ще до коду.

Кейс 2. Правило трьох: як відрізнити абстракцію від передчасного вгадування

Приходить PR: другий за тиждень тест на «список» (спершу список замовлень, тепер список рахунків), і автор одразу виносить BaseListPage з дженериком і хуками «на майбутнє».

// Узагальнення на основі ДВОХ екранів
abstract class BaseListPage<TRow> {
  abstract get rowSelector(): string;
  async openWithRetries(times = 3): Promise<void> { /* ще нікому не треба */ }
  async waitForAnalytics(): Promise<void> { /* ще нікому не треба */ }
  async sortBy(col: string, dir: 'asc' | 'desc'): Promise<TRow[]> { /* ... */ }
}

Реакція на рев'ю — не «гарна архітектура», а питання: у нас два списки чи три? Бо два приклади показують вісь варіативності неправдиво. Проженемо по «правилу трьох»:

openWithRetries і waitForAnalytics тут узагалі рішення проблем, яких немає, — чистий YAGNI. А сам BaseListPage, вгаданий з двох екранів, майже напевно не влізе на третій: у рахунків з'явиться пагінація, якої не було в замовлень, і базовий клас обросте прапорцями. Порада в PR: залишити два списки як є, дубль стерпіти, а до узагальнення повернутися, коли прийде третій реальний випадок.

Що дивитися і чому:

• Новий «універсальний» базовий клас під один-два кейси — червоний прапор рев'ю. Питання «це вже треба, чи YAGNI?» доречніше за схвалення передбачливості.
• Хуки «на виріст» (waitForAnalytics) видаляємо одразу. За них платять підтримкою вже сьогодні, а окупність гіпотетична.
• Два приклади брешуть, три показують вісь. Це не бюрократія, а спосіб не вгадати форму абстракції неправильно й не переробляти її потім через прапорці.

Кейс 3. Від ланцюга успадкування до фікстур: розплутуємо BaseTest

Класична спадщина зрілого фреймворку — ланцюг, який виріс «логічними кроками»:

// БУЛО: is-a на чотири рівні
class BaseTest { /* setup/teardown */ }
class BaseUiTest extends BaseTest { /* + браузер */ }
class BaseAuthTest extends BaseUiTest { /* + автологін, зашитий посередині */ }
class CheckoutTest extends BaseAuthTest { /* власне тест */ }

Болить одразу все: щоб зрозуміти CheckoutTest, треба тримати в голові всіх предків і порядок їхніх setup; зміна в BaseTest розходиться по всіх нащадках непередбачувано (крихкий базовий клас); а зробити тест з браузером, але без автологіну неможливо — логін «зашитий» посередині ланцюга. І головне: CheckoutTest не є різновидом BaseAuthTest, він просто хоче користуватися логіном. Це has-a, натягнуте на is-a. Переписуємо на композицію — тест явно оголошує, що йому треба:

// СТАЛО: has-a через фікстури, поведінка збирається видимо й плоско
export const test = base.extend<{ authedPage: Page; cart: CartPage }>({
  authedPage: async ({ page }, use) => {
    await loginAs(page, users.premium);
    await use(page);
  },
  cart: async ({ authedPage }, use) => {
    await use(new CartPage(authedPage));
  },
});

test('кошик рахує суму', async ({ cart }) => {
  // з сигнатури видно: тесту треба кошик поверх залогіненої сторінки — і все
  await cart.open();
  await expect(cart.total).toHaveText('₴1200');
});

Той самий перехід — усередині page object: сторінка не успадковує хедер, а містить компоненти як поля.

// has-a: сторінка складається з компонентів, а не успадковує їх
class CheckoutPage {
  readonly header = new HeaderComponent(this.page);
  readonly cart = new CartComponent(this.page);
  constructor(private page: Page) {}
}

Що дивитися і чому:

• Тест, якому браузер потрібен без автологіну, більше не «не вписується». Він просто не оголошує фікстуру authedPage — комбінацію збирають під конкретний кейс, а не фіксують у ланцюзі предків.
• Cmd+click веде на реальний код, а не на порожній абстрактний метод. Фікстура — це видиме джерело поведінки, а не рівень ієрархії, який треба тримати в голові.
• Один тонкий рівень — це нормально. class HeaderComponent extends BaseComponent з полем page — законне «є». Правило про глибину й мотив, а не про заборону extends як такого.

DRY і DAMP

• Знаю, що DRY стосується дублювання знання (одного рішення в кількох місцях), а не візуально схожих рядків.
• Розумію правило межі: DRY на механіку (логін, підготовка даних, навігація), DAMP на намір (arrange-дані сценарію й усі expect).
• Можу пояснити, що таке DAMP і чому в тестах читабельність важливіша за мінімізацію рядків.
• Знаю, чому винесення expect у спільний хелпер ховає суть перевірки й ускладнює діагностику падіння.
• Можу відрізнити справжній дубль (однакове рішення) від випадкового збігу двох незалежних фрагментів.

KISS

• Розумію KISS як «найпростіше рішення, що працює» і чому складний тест сам підриває довіру до себе.
• Знаю, що KISS у тестах часто означає «довіряй інструменту»: web-first assertion замість ручного polling.
• Можу назвати симптоми порушення KISS: обгортка над expect, зайва регулярка, рукотворний retry, генерація даних циклом із розгалуженнями.

YAGNI і передчасні абстракції

• Розумію YAGNI: не будувати функціональність, поки вона реально не знадобилась.
• Можу пояснити, чому передчасна абстракція в тестах дорожча — платиш підтримкою вже, а форму вгадуєш з одного-двох кейсів неправильно.
• Знаю «правило трьох»: виносити спільне лише на третьому подібному випадку, бо два приклади брешуть про вісь варіативності.
• Можу навести приклад передчасної абстракції: «фреймворк на виріст», шар над Playwright «щоб легко переїхати», базовий клас під один екран.

Композиція проти успадкування

• Знаю різницю has-a (композиція, «має») vs is-a (успадкування, «є») і правило «надавай перевагу композиції над успадкуванням».
• Можу перелічити болі глибокої ієрархії: крихкий базовий клас, вертикальне читання, жорсткість комбінацій, успадкування заради перевикористання.
• Розумію, як фікстури Playwright (test.extend) реалізують композицію — тест явно оголошує потрібні здатності в сигнатурі.
• Знаю, що композиція в page object — це компоненти (header, cart) як поля, а не ланцюг extends.
• Можу сказати, коли успадкування виправдане: справжнє «є» плюс неглибокий ланцюг (тонкий BaseComponent з полем page).

Код-рев'ю тестового коду

• Знаю, чим рев'ю тестів відрізняється від продуктового: головне — читабельність наміру й стійкість до редизайну, а не ефективність.
• Можу перелічити, на що дивитись: намір без стрибків у хелпери, стабільні локатори, відсутність waitForTimeout, незалежність та ізоляція, свіжість даних, відсутність передчасних абстракцій.
• Пам'ятаю евристику: якщо для розуміння одного тесту треба відкрити більше двох-трьох файлів — абстракцій забагато.