Піраміда тестування: рівні, вартість, антипатерни

Що таке піраміда тестування і навіщо про неї питають на співбесіді?

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

Які рівні автотестів виділяють і за чим вони відрізняються?

Класично чотири, і головна вісь між ними — обсяг застосунку, який тест піднімає заради однієї перевірки. Unit ганяє одну функцію в ізоляції, без мережі й бази. Інтеграційні (integration/component) з'єднують кілька одиниць: сервіс із реальною БД або UI-компонент із залежностями. API/сервісні б'ють у застосунок через HTTP без інтерфейсу. E2E проганяють усе через UI, як живий користувач. Що більше системи в грі, то повільніше, крихкіше й дорожче — тому знизу вгору тестів має ставати менше.

Чим unit-тест принципово відрізняється від E2E?

Масштабом того, що він тримає під час перевірки, і, як наслідок, ціною. Unit працює з однією функцією чи класом без жодних зовнішніх залежностей, відпрацьовує за мілісекунди й на червоному одразу тицяє в конкретне місце коду. E2E піднімає реальний браузер, ходить у мережу, чіпає базу й сторонні сервіси — секунди-хвилини на кейс, а на червоному каже лише «десь на шляху зламалося». Тому unit-ів у здоровому наборі тисячі, а E2E — одиниці: перші дешеві й точні, другі дорогі, але єдині підтверджують, що вся система справді стикується.

Чому чим вище рівень, тим дорожчий тест?

Бо вартість росте одразу за чотирма незалежними осями, і вони перемножуються. Перша — швидкість зворотного зв'язку: тисячу unit-ів проженеш за секунди й побачиш регресію ще до коміту, а повільна E2E-сюїта просто перестає запускатися на кожен PR. Друга — локалізація фейлу: unit показує пальцем на функцію, E2E лишає тебе відтворювати проблему. Третя — флакі: більше рухомих частин (мережа, анімації, таймінги) означає більше приводів моргнути. Четверта — підтримка: переверстали кнопку, і локатор верхнього тесту впав. Разом це означає, що баг, спійманий unit-ом за секунду, з червоного E2E доводиться діставати хвилинами.

Що таке правило найнижчого рівня?

Головна евристика піраміди: кожен дефект перевіряй на найнижчому рівні, де його ще реально зловити. Логіка знижки — це unit; те, що ендпоінт кошика цю знижку застосовує — API; а наскрізний шлях користувача до оплати лишається одним димовим E2E. Сенс у тому, що чим нижче зловив баг, тим дешевше він тобі обійшовся — і за прогоном, і за діагностикою. Правило заразом підказує, де НЕ дублювати: одна й та сама перевірка на трьох рівнях — це витрати без нової впевненості.

E2E зловив регресію, а жоден нижчий тест не впав. Що це означає?

Що в тебе дірка на нижньому рівні, а не привід радіти, що E2E «врятував». Якщо баг був у бізнес-логіці, його мав би зловити unit або API-тест — раз вони мовчали, значить, цієї перевірки внизу просто немає. Правильна реакція: додати дешевий тест на потрібному рівні, а E2E лишити для того, що тільки він і підтверджує — цілісність наскрізного шляху. Це прямий наслідок правила найнижчого рівня, і його часто чекають на співбесіді слідом за самою пірамідою.

Де в піраміді API-тести і чому продуктові QA їх так люблять?

Це талія піраміди — рівень між інтеграційними й E2E, де б'ють у застосунок через HTTP чи сервісний шар без інтерфейсу. Люблять за поєднання якостей, якого немає більше ніде: тести швидкі (сотні мілісекунд проти секунд у E2E), стабільні (немає верстки, анімацій і браузерних таймінгів, які флакають), близькі до бізнес-логіки й не ламаються від того, що дизайнер посунув кнопку. Для продуктового QA це часто найцінніший рівень: максимум впевненості за мінімум крихкості. На співбесіді відповідь «талія — швидко, стабільно, без залежності від UI» — саме те, що хочуть почути.

Скільки має бути E2E-тестів у проєкті?

Це пастка на конкретну цифру — правильна відповідь не «десять відсотків», а «стільки, скільки в нас критичних наскрізних шляхів». Магічного відсотка E2E не існує; питання не «яка пропорція», а «які саме сценарії ніхто, крім повного прогону через UI, підтвердити не може». Логін-оплата, реєстрація, ключовий бізнес-флоу — так; двісті E2E на бізнес-правила, які мали б жити в unit — ні. Усе, що можна перевірити нижче, туди й спускай, а нагорі лишай тонкий шар димових перевірок реальних шляхів користувача.

Що таке «ріжок морозива» і чим він поганий?

Це перевернута піраміда: гора E2E й ручних перевірок угорі, майже порожньо внизу. Симптоми впізнає кожен, хто на такому працював — сюїта повзе десятки хвилин, регулярно червоніє через таймінги, а не через реальні баги, і будь-яка зміна інтерфейсу вимагає ремонту десятків тестів. Виникає, коли QA прикручують у кінці процесу, розробники unit-ів не пишуть, а команда виправдовується «ми ж тестуємо через інтерфейс, як користувач». Підсумок парадоксальний: це найдорожчий спосіб отримати найменше впевненості.

А що таке «пісочний годинник» і чим він відрізняється від ріжка?

Це деформація з товстим низом і товстим верхом, але тонкою талією: багато unit і багато E2E, майже нічого на рівні API та інтеграційних. Команда старанно покрила окремі одиниці й наскрізні клікання, але пропустила саме той шар, де живе більшість інтеграційних багів — стики модулів і контракти сервісів. Проблема в тому, що дефект стику unit не бачить за визначенням, тож ловити його доводиться найдорожчим E2E, і талію годинника постійно роздуває. На відміну від ріжка, тут внизу все гаразд — провалена середина.

Як лікувати деформовану піраміду?

Незалежно від форми — переносити перевірки вниз. Береш найповільніші й найкрихкіші E2E-тести і питаєш по кожному: чи можна цей самий інваріант перевірити на API або unit? Здебільшого можна — бізнес-правило спускається в unit, перевірка контракту ендпоінта в API, а на верхньому рівні лишається димовий сценарій шляху. Це знімає і час прогону, і флак, і вартість підтримки одразу. Лікування ріжка морозива й пісочного годинника по суті однакове: центр ваги набору має опуститися ближче до дешевих рівнів.

Чи правда, що піраміда наказує пропорцію 70/20/10?

Ні, і це поширений міф — жодну конкретну цифру ні Кон, ні Фаулер не проголошували. Пропорцію часто цитують, наче норматив, але це радше зручна ілюстрація, ніж закон. Реальна пропорція контекстна: вона залежить від архітектури й ризиків, а не від магічного відсотка. Сильна відповідь на співбесіді якраз розрізняє «орієнтир форми» і «жорсткий норматив»: піраміда каже, що дешевих тестів має бути більше за дорогі, але не диктує точних чисел.

Що таке testing trophy і чим він відрізняється від піраміди?

Це модель Кента Доддса на чотири рівні: статичний аналіз (типи, лінтер) унизу, потім unit, найширшим шаром — інтеграційні, а зверху E2E. Ключова відмінність від класичної піраміди — центр ваги зсунуто на інтеграційні тести, а не на unit. Логіка в тому, що для JavaScript-фронтенду тест компонента разом із його залежностями дає краще співвідношення впевненості до вартості, ніж ізольований unit, який мокає пів світу. Девіз трофея — «чим більше тести нагадують реальне користування, тим більше впевненості вони дають»; корінь ідеї — фраза Рауха «Пишіть тести. Не забагато. Здебільшого інтеграційні».

Піраміда застаріла? Що відповісти, коли її називають догмою минулого?

Не застаріла — просто це орієнтир під конкретний контекст, а не універсальний закон. Крізь усі моделі — піраміду, трофей, стільник (honeycomb) від Spotify — проходить один інваріант: дешеві, швидкі, стабільні тести мають переважати, а повільні й дорогі бути нечисленними й зарезервованими під те, що тільки вони підтвердять. Що змінюється — це де саме центр ваги: для фронтенду він у інтеграційних тестах, для мікросервісів — у контрактних, для CLI-утиліти верхнього шару може не бути взагалі. Питання не «чи схожа моя сюїта на трикутник», а «який найдешевший рівень дасть цю конкретну впевненість».

API-тест — це unit чи інтеграційний? Як правильно?

На практиці ярлик не важить, і суперечка про нього — червоний прапорець на співбесіді. Слово «інтеграційний» кожна команда розуміє по-своєму: хтось зве API-тести інтеграційними, хтось сервісними, а Фаулер узагалі розрізняє «вузькі» й «широкі» інтеграційні. Важить не назва папки, а три речі — який обсяг системи тест піднімає, як швидко відпрацьовує і скільки коштує підтримувати. Правильна поведінка не воювати за термінологію, а домовитися в команді, що на кожному рівні перевіряється — а на співбесіді показати, що ти оцінюєш тест за вартістю, а не за міткою.

Чому не варто дублювати одну й ту саму перевірку на кількох рівнях?

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

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

Кейс 1. Розкласти фічу по рівнях: промокод на кошик

Прийшла задача: промокод SAVE20 дає 20% знижки на замовлення від 500 грн, не сумується з іншими акціями, діє до кінця місяця. Спокуса — написати п'ять E2E, які проходять весь шлях «увести код → побачити суму». Спокусі не піддаємося: розкладаємо перевірки за обсягом системи, який кожна вимагає.

На виході піраміда в мініатюрі: десяток unit-кейсів на математику й межі, три-чотири API-тести на проводку й несумісність, рівно один димовий E2E на весь шлях. Питання, яке веде розкладку, одне на кожен рядок: чи є нижчий рівень, здатний зловити цей самий дефект? Якщо є — перевірка йде туди.

Кейс 2. Діагноз «ріжок морозива» за симптомами

Заходиш на проєкт, дивишся на CI — і бачиш знайому картину. Ось як відрізнити деформацію від просто «поганого дня» набору.

Suite: checkout-e2e        212 тестів    38 хв    ~9% flaky
Suite: cart-unit             14 тестів     3 с    0% flaky
Suite: api                    0 тестів      —      —

Симптоми, що прямо вказують на перевернуту піраміду:

• Прогін десятки хвилин, а тестів переважно нагорі. 212 E2E проти 14 unit і нуля API — центр ваги задертий угору.
• Флак не через баги, а через таймінги. 9% нестабільності на E2E-сюїті означає, що частина червоного — це моргання мережі й анімацій, а не регресії. Такий набір перестають запускати на кожен PR.
• Кожна зміна UI ламає десятки тестів. Переверстали кошик — і половина з 212 локаторів поїхала.

Що з цим робити — не переписувати все за раз, а міряти вартість і спускати найдорожче:

1. Відсортуй E2E за часом і за частотою флаку — це список кандидатів на переселення.
2. По кожному спитай: цей тест перевіряє наскрізний шлях чи бізнес-правило, замасковане під клікання? Правила — вниз.
3. Спочатку піднімай відсутній рівень API: більшість «checkout» перевірок насправді про контракт ендпоінта, а не про верстку.
4. Наверху лишай тонкий шар димових сценаріїв реальних шляхів користувача — решту логіки покрито дешевше.

Ключове: мета не «зробити трикутник гарним», а прибрати найповільніші й найкрихкіші перевірки з гарячого шляху зворотного зв'язку.

Кейс 3. Спустити перевірку з E2E у нижчий рівень

Ось типовий «дорогий» тест, який перевіряє бізнес-правило через увесь інтерфейс. Він працює, але піднімає браузер, ходить у мережу й флакає на кожній зміні верстки кошика.

// БУЛО: бізнес-правило знижки перевіряють через повний UI
test('замовлення понад 1000 отримує знижку 15%', async ({ page }) => {
  await page.goto('/product/A');
  await page.getByRole('button', { name: 'Додати в кошик' }).click();
  await page.getByRole('button', { name: 'Додати в кошик' }).click(); // сума > 1000
  await page.getByRole('link', { name: 'Кошик' }).click();
  await expect(page.getByTestId('cart-total')).toHaveText('1700');
});

Питання за правилом найнижчого рівня: що цей тест насправді перевіряє? Математику знижки — а вона живе в чистій функції. Спускаємо ядро логіки в unit, де немає ні браузера, ні мережі:

// СТАЛО (unit): межі й математика — дешево й точно
import { calculateDiscount } from '../src/pricing';

test('знижка 15% лише понад 1000', () => {
  expect(calculateDiscount(1000)).toBe(0);    // рівно на межі — без знижки
  expect(calculateDiscount(0)).toBe(0);       // нуль — без знижки
  expect(calculateDiscount(2000)).toBe(300);  // 15% від 2000
});

Те, що ендпоінт кошика цю функцію реально викликає й повертає правильний підсумок, підтверджуємо одним API-тестом без UI:

// СТАЛО (API): проводка через сервіс, швидко й стабільно
test('кошик віддає total зі знижкою', async ({ request }) => {
  const res = await request.post('/api/cart', {
    data: { items: [{ sku: 'A', price: 2000, qty: 1 }] },
  });
  expect(res.status()).toBe(200);
  expect((await res.json()).total).toBe(1700);
});

А E2E лишається — але вже не як перевірка математики, а як димовий доказ, що користувач узагалі доходить до підсумку й бачить його на екрані. Результат перенесення: межі знижки покрито десятком unit-кейсів за мілісекунди, проводку — стабільним API-тестом, а крихкий повільний шлях через браузер звужено до одного сценарію замість перевірки бізнес-правил кліканням.

Рівні тестування

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

Чому вгору дорожчає

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

Правило найнижчого рівня

• Можу сформулювати правило: лови кожен дефект на найнижчому рівні, де його ще реально зловити.
• Розумію наслідок: якщо E2E зловив баг, а нижче нічого не впало — це дірка на нижньому рівні, а не привід радіти.
• Знаю, чому не варто дублювати одну перевірку на трьох рівнях (вартість без нової впевненості).
• Можу показати один інваріант (знижку) на трьох рівнях: unit — математика, API — проводка через ендпоінт, E2E — димовий шлях.

Антипатерни форми

• Розрізняю ріжок морозива (перевернута піраміда: гора E2E внизу порожньо) і його симптоми: повільність, флакі, дорога підтримка.
• Розрізняю пісочний годинник (товсті низ і верх, тонка талія) і розумію, що провалено рівень інтеграційних багів.
• Знаю універсальне лікування обох деформацій: переносити перевірки вниз, з E2E на API/unit.

Моделі й контекст

• Можу описати testing trophy Доддса (статичний аналіз, unit, інтеграційні найширші, E2E) і чому центр ваги там на інтеграційних.
• Знаю модель «стільник» (honeycomb) для мікросервісів і що вага там зміщена до інтеграційних та контрактних тестів.
• Розумію, чому 70/20/10 — міф, а не норматив, і що пропорція залежить від архітектури й ризиків.
• Можу відповісти на «скільки E2E»: стільки, скільки критичних наскрізних шляхів, а не фіксований відсоток.
• Розумію, чому суперечка «API-тест — unit чи інтеграційний» безплідна: важить обсяг, швидкість і вартість, а не ярлик.