TypeScript: типи, інтерфейси та строгий режим

Що таке TypeScript і чому його називають надбудовою над JavaScript?

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

Навіщо автотестам типізація, які проблеми вона знімає?

Автотест живе роками, його читають і правлять різні люди, тож ціна одруку висока. Типи дають три конкретні речі: чесне автодоповнення (редактор сам показує методи типізованого APIRequestContext і форму відповіді), безстрашний рефакторинг (переназвав поле у фікстурі — компілятор підсвітив усі місця, що на нього спиралися) і цілий клас помилок, який просто зникає. Сюди входять забутий await (де замість значення лишається Promise), звернення до поля того, що може бути undefined, і передавання не того типу аргумента. Важливо розуміти межу: типи прибирають баги в коді тесту, але не перевіряють, чи застосунок реально повернув те, що ти описав. Тому типізація доповнює перевірки, а не заміняє їх.

Що означає, що типи існують лише під час компіляції?

Це і є стирання типів (type erasure): усі анотації живуть тільки на етапі перевірки, а перед запуском компілятор їх викидає й лишає голий JavaScript. У рантаймі жодного поняття «тип» уже немає — Node виконує код так, наче TypeScript ніколи й не було. Практичний наслідок один і болючий: TS ловить лише те, що видно зі статичного аналізу тексту програми, і безсилий проти всього, що визначається під час виконання. Не можна, наприклад, у if спитати «а це справді User?» через сам тип — для рантайм-перевірки потрібен звичайний JS-код (typeof, in, перевірка полів). Розуміння цієї межі майже завжди питають, бо воно відділяє тих, хто вивчив синтаксис, від тих, хто зрозумів модель.

Що таке виведення типів і де тоді потрібні явні анотації?

Виведення типів (type inference) — це коли TypeScript визначає тип сам із контексту, без твоєї підказки: let title = "Login" дає string, а const retries = 3 — літеральний тип 3. Через це анотувати кожен рядок не треба й навіть шкідливо — зайві анотації засмічують код і застарівають. Ставити явний тип варто там, де виведення не спрацьовує або небезпечне: у параметрах функцій (їх компілятор угадати не може) і там, де хочеш зафіксувати ширший чи чіткіший контракт, ніж дає початкове значення. Практичне правило для тестів — анотуй межі: параметри, публічні сигнатури функцій, форму фікстур і тестових даних, а локальні змінні лишай на виведення. Так типів рівно стільки, скільки треба, і жодного зайвого шуму.

Чому const status = 200 і let status = 200 мають різні типи?

Тому що виведення враховує можливість переприсвоєння. У const status = 200 значення змінити не можна ніколи, тож TypeScript звужує тип до літерального 200 — це точно двохсотка й нічого іншого. У let status = 200 змінну дозволено переприсвоїти будь-яким числом, тому компілятор виводить ширший тип number. Різниця не косметична: літеральний тип від const дозволяє передати значення туди, де очікують саме 200, а number — ні. На цьому ж механізмі тримаються union літералів: щоб масив рядків став набором конкретних варіантів, а не просто string[], застосовують as const. Плутанина «чому мій const-рядок не пасує до union літералів, а let тим паче» — типове джерело здивування новачків.

Чим кортеж відрізняється від звичайного масиву?

Масив (number[] або Array<number>) — це однорідні елементи довільної довжини: усі одного типу, скільки їх — невідомо. Кортеж (tuple) — навпаки, фіксована довжина, де тип кожної позиції відомий заздалегідь: [string, number] означає рівно два елементи, спершу рядок, потім число. Тобто масив описує «багато однакового», а кортеж — «конкретна структура за позиціями». Кортежі зручні, коли функція повертає кілька значень для деструктуризації за позицією — наприклад, пара [дані, помилка]. У щоденному тестовому коді вони трапляються нечасто, але їх люблять питати саме тому, що по відповіді одразу видно, чи людина розуміє різницю між довжиною й формою.

Чому string пишуть з малої літери, а String — майже завжди помилка?

string, number, boolean з малої — це примітивні типи TypeScript, і саме їх треба вживати. String, Number, Boolean з великої — це типи обʼєктів-обгорток навколо примітивів, які на практиці майже ніколи не потрібні. Різниця не суто стилістична: обгортка не взаємозамінна з примітивом там, де очікують примітив, тож String замість string тягне дивні помилки сумісності типів. Редактор зазвичай і сам підказує малу форму. Просте правило — у власному коді завжди пиши примітиви з малої, а велику форму сприймай як сигнал, що хтось помилився.

Чим type відрізняється від interface?

Це один із найчастіших запитів співбесіди, і слабка відповідь «нічим» або «interface лише для обʼєктів» одразу видає поверхове знання. Чесно: для опису форми обʼєкта вони майже взаємозамінні. Різниця в тому, що кожен уміє ексклюзивно. type — це імʼя (псевдонім, type alias) для будь-якого типу: тільки через нього описують union, кортеж, примітив чи функцію, наприклад type Method = "GET" | "POST"; розширюють його перетином &. interface описує лише форму обʼєкта, розширюється через extends і вміє те, чого не вміє type, — злиття оголошень (declaration merging). Звідси й практичне правило: бери interface за замовчуванням, а type — коли треба union, літерали, кортеж чи локальне скорочення.

Що таке declaration merging і навіщо це фреймворкам?

Declaration merging (злиття оголошень) — це здатність interface: два інтерфейси з однаковим імʼям TypeScript автоматично зливає в один сумарний тип. Псевдонім type так не вміє — два type з однаковим імʼям дадуть помилку повторного оголошення. На перший погляд дивна фіча, але вона критична для розширюваних API: фреймворк оголошує interface для типу, який користувач має доповнювати своїми полями, і твоє доповнення просто зливається з базовим. Класика для AQA — кастомні фікстури Playwright: ти розширюєш інтерфейс фікстур своїми, і типізація бачить і рідні, і твої. Саме тому такі точки розширення роблять на interface, а не на type — щоб їх можна було догорнути ззовні.

Що таке union і literal types і навіщо вони в автотестах?

Union type (обʼєднання) — це значення одного з кількох типів через вертикальну риску: string | number. Він потрібен щодня, бо реальні дані рідко одного типу — той самий id буває і числом, і рядком. Literal type (літеральний тип) — це не «якийсь рядок», а конкретне значення, підняте до рівня типу: type Status = "passed" | "failed" | "skipped" дозволяє тільки ці три рядки й жоден інший. У парі вони дають потужний ефект в автоматизації: замість «магічних рядків», де легко зробити одрук, компілятор гарантує дозволене значення, а редактор пропонує варіанти автодоповненням. Передав report("blocked") замість дозволеного статусу — помилка ще до запуску. Працює це і для чисел (0 | 1 | 2), і для змішаних наборів.

У чому різниця між any і unknown?

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

Що таке тип never і де він виникає?

never — це тип, що не має жодного значення, «дно» системи типів; у нього неможливо нічого покласти. Він природно зʼявляється у двох місцях. Перше — функція, що ніколи не повертає керування нормально: завжди кидає виняток або крутиться в нескінченному циклі, тож і повертати їй нема чого. Друге, практичніше, — недосяжна гілка коду: якщо ти вичерпав усі варіанти union літералів у switch, у гілці default тип звужується до never. Це дає перевірку на вичерпність (exhaustiveness): додав новий варіант у союз і забув обробити — компілятор поскаржиться, бо значення більше не влазить у never. Тобто never перетворює «забув гілку» на помилку компіляції, і це його головна користь на практиці.

Що робить прапорець strictNullChecks і навіщо він?

strictNullChecks вирішує, чи можна класти null і undefined куди завгодно. Коли він вимкнений (стара небезпечна поведінка), ці значення сумісні з будь-яким типом: змінна string спокійно приймає null, компілятор мовчить — рівно до рантайму, де вилітає класичне Cannot read properties of null. Коли ввімкнений (правильний режим, частина сімейства strict), null і undefined стають окремими типами: якщо значення може бути «нічим», це доводиться описати явно (string | null), і компілятор змушує обробити цей випадок, перш ніж чіпати значення. По суті прапорець перетворює найпоширеніший клас рантайм-падінь на помилку ще на етапі перевірки — саме заради цього TypeScript часто й беруть. У тестах це особливо цінно: null з локатора перестає бути тихою міною.

Що таке оператор ! (non-null assertion) і чому це пастка?

Знак оклику після значення (cell!.trim()) каже компілятору: «повір, тут не буде null чи undefined». Виглядає як зручний спосіб прибрати червоне підкреслення, і саме тому він небезпечний. ! нічого не перевіряє в рантаймі — він лише вимикає перевірку компілятора й повертає тебе в світ без типів. Якщо значення реально виявиться null, тест упаде з тим самим Cannot read properties of null, від якого strictNullChecks мав тебе вберегти. У тестовому коді це підступно вдвічі: null з локатора часто не випадковість, а справжній сигнал, що елемента немає або сторінка не догрузилась, — а ! цей сигнал глушить. Майже завжди правильна заміна — явна перевірка через if, а в Playwright краще взагалі не діставати текст руками, а користуватися web-first асертами (await expect(locator).toHaveText(...)), які самі чекають і не повертають null.

Що робить знак ? після імені поля чи параметра?

Знак питання робить поле або параметр опціональним: його може не бути взагалі, а до типу автоматично додається undefined. Тобто timeout?: number — це фактично number | undefined, і викликач має право не передавати значення. Це зручно для конфігів і опцій, де частина полів необовʼязкова. Але за ввімкненого strictNullChecks опціональність не безкоштовна: перш ніж використати таке поле, компілятор змусить пересвідчитися, що воно не undefined. Тому опціональні поля — це не «поле, яке я іноді ігнорую», а «поле, до якого домальовано undefined, і його треба обробити». Плутанина між «поля немає» і «поле є, але дорівнює undefined» — типова тонкість, яку інколи й перевіряють.

Чим enum відрізняється від union літералів і що обрати в тестовому коді?

enum дає імена набору повʼязаних констант і звичний вигляд для тих, хто прийшов з Java чи C#. Але в TypeScript у нього є нюанс: на відміну від решти системи типів, звичайний enum не стирається — він компілюється в реальний обʼєкт, що лишається в рантаймі, а числовий ще й додає зворотний мапінг (і за іменем, і за числом), який іноді дивує. Union літералів натомість існує лише як тип і зникає при компіляції безслідно. Для більшості випадків в автоматизації union робить те саме, але легший і без сліду в зібраному JS. Enum виправданий тоді, коли значення справді треба перебирати в рантаймі як колекцію (обʼєкт для цього вже існує); в решті випадків типовий сучасний вибір — type з union літералів, за потреби доповнений as const-обʼєктом.

Чи впіймає TypeScript, що API повернув рядок замість числа?

Ні — і це улюблена пастка на плутанину компіляції та рантайму. Якщо ти описав відповідь як { id: number }, а сервер прислав { id: "42" }, TypeScript цього не побачить: його перевірка закінчилась на етапі компіляції, а дані приходять під час виконання, коли типів уже немає. Анотація описує твоє очікування, а не гарантує реальність — вона нічого не звіряє з тим, що прилетіло по мережі. Щоб упіймати таку розбіжність, потрібна рантайм-валідація схемою (zod, ajv тощо), яка перевіряє справжню відповідь під час виконання. Тому типізація й рантайм-перевірки — це два різні шари: перший стереже код тесту, другий — контракт застосунку, і один одного вони не заміняють.

Три ситуації з тестового коду, де типи вирішують, зелений тест чи тихий баг: як оператор ! глушить справжній сигнал у Playwright, як обрати між type та interface для тестових типів, і чому await response.json() треба зустрічати типом unknown, а не any. Скрізь — що дивитися і чому.

Кейс 1. Оператор ! ховає справжню причину падіння

Тест дістає підсумкову суму з таблиці й порівнює її. textContent() у Playwright повертає string | null, тож за ввімкненого strictNullChecks компілятор підкреслює cell.trim(): «cell може бути null». Найшвидший спосіб прибрати червоне — дописати !. Саме так у код і потрапляє міна:

// погано: ! вимикає перевірку, але нічого не гарантує
const cell = await page.locator('.total').textContent();
const total = cell!.trim(); // якщо textContent поверне null — TypeError у рантаймі

Проблема не в тому, що впаде тест, а в тому, що він упаде не там і не з тим повідомленням. null тут — це не випадковість, а сигнал: рядок .total не знайдено, сторінка не догрузилась або елемент іще порожній. Оператор ! цей сигнал глушить і перетворює осмислений діагноз на голе Cannot read properties of null десь нижче за стеком.

Явна перевірка повертає сигнал на місце:

const cell = await page.locator('.total').textContent();
if (cell === null) {
  throw new Error('Елемент .total не знайдено або порожній — перевір локатор і стан сторінки');
}
const total = cell.trim(); // тут TS упевнений, що це string

Але в Playwright є ще краще рішення — взагалі не діставати текст руками. Web-first асерт сам чекає на елемент і не повертає null:

// найнадійніше: асерт з автоочікуванням, жодного null у грі
await expect(page.locator('.total')).toHaveText('1 200 грн');

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

• ! не додає перевірки — він її прибирає. Це не «я впевнений, що не null», а «не перевіряй за мене». Компілятор замовкає, ризик лишається цілим.
• null з локатора майже завжди інформативний. Він каже про стан сторінки, а не про примху типів; тест має впасти з цим діагнозом, а не з абстрактним TypeError.
• Web-first асерти прибирають саме джерело null. toHaveText, toBeVisible чекають на елемент і не змушують тебе тримати руками значення, яке може виявитися порожнім.

Кейс 2. type чи interface для тестових типів — таблиця рішень

Питання «type чи interface» на практиці зводиться не до смаку, а до того, що з типом робитимуть далі. Ось типові тестові сутності й обґрунтований вибір:

Практичне правило під це: форму обʼєкта (відповідь, Page Object, конфіг) описуй interface за замовчуванням, а type тримай для union літералів і локальних аліасів. Приклад із життя фікстур, де вибір змушений:

// interface — бо його треба ДОПОВНИТИ ззовні; type тут не спрацював би
import { test as base } from '@playwright/test';

interface AppFixtures {
  loginAsAdmin: () => Promise<void>;
}

// union літералів — тільки type
type UserRole = 'admin' | 'editor' | 'viewer';

interface ApiUser {
  id: number;
  email: string;
  role: UserRole; // union усередині форми обʼєкта
}

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

• Declaration merging — єдиний по-справжньому змушений критерій. Якщо тип мають доповнювати ззовні (фікстури, матчери), це interface, і крапка.
• Union, літерали, кортеж — територія type. Спроба описати їх інтерфейсом просто не скомпілюється.
• «Взаємозамінні» стосується лише простої форми обʼєкта. Щойно зʼявляється розширюваність або union — вибір перестає бути справою смаку.

Кейс 3. await response.json() — чому unknown, а не any

Тіло відповіді приходить у рантаймі, коли типів уже немає, тож TypeScript не знає його форми. Спокуса — приписати any й забути; насправді це відчиняє діру, що протікає далі кодом:

// погано: any вимикає перевірки скрізь, куди потрапить data
const data: any = await response.json();
data.usr.id; // одрук usr замість user — компілятор мовчить, впаде в рантаймі

unknown змушує спершу переконатися, що прийшло те, що ти думаєш, і аж потім чіпати поля:

const data: unknown = await response.json();

// звуження: перевіряємо форму, перш ніж довіряти їй
if (
  typeof data === 'object' && data !== null &&
  'user' in data && typeof (data as { user: unknown }).user === 'object'
) {
  // тут уже безпечніше працювати з data.user
}

Але ключова думка глибша: навіть акуратне звуження перевіряє форму лише настільки, наскільки ти сам її прописав, і не гарантує контракту. Якщо треба справді впевнитися, що API віддав { id: number }, а не { id: "42" }, потрібна рантайм-схема — TypeScript цього не зловить у принципі:

import { z } from 'zod';

const UserSchema = z.object({ id: z.number(), email: z.string() });

const raw = await response.json();
const user = UserSchema.parse(raw); // впаде тут з чітким описом, ЩО саме не так
// user типізований як { id: number; email: string } і вже звірений із реальністю

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

• any заразний, unknown — ні. any глушить перевірки в усьому ланцюжку, unknown тримає значення «замкненим», поки ти не доведеш його форму.
• Звуження типу — це рантайм-код, а не тип. typeof, in, перевірка полів працюють під час виконання; сам тип нічого не перевіряє.
• Типи не заміняють валідацію контракту. Форму реальної відповіді звіряють схемою (zod/ajv); анотація описує очікування, схема — перевіряє факт.

Природа TypeScript

• Можу пояснити, чому TypeScript — надбудова (superset): будь-який валідний JS є валідним TS, типи лише додаються зверху.
• Розумію стирання типів (type erasure): анотації живуть тільки під час компіляції й зникають перед запуском, у рантаймі типів немає.
• Знаю межу інструмента: TS ловить помилки в самому тестовому коді, але не перевіряє, що застосунок реально повернув описану форму.

Анотації та виведення

• Розумію виведення типів (inference) і чому анотувати кожен рядок шкідливо: TS сам визначає локальні типи з контексту.
• Знаю правило «анотуй межі»: параметри функцій, публічні сигнатури, форму фікстур — а локальні змінні лишай на виведення.
• Можу пояснити, чому const x = 200 має тип 200 (літерал), а let x = 200 — ширший number.

Базові типи, масиви, кортежі

• Знаю, що примітиви пишуться з малої (string, number, boolean), а String/Number з великої — обгортки й майже завжди помилка.
• Можу пояснити різницю масив vs кортеж (tuple): масив — багато однакового невідомої довжини, кортеж — фіксована довжина з типом кожної позиції.

type проти interface

• Знаю, що для форми обʼєкта type та interface майже взаємозамінні, і чесно кажу це замість «interface лише для обʼєктів».
• Можу назвати ексклюзив type: union, літерали, кортеж, примітив, функція — усе це тільки через нього.
• Можу назвати ексклюзив interface: злиття оголошень (declaration merging), через яке фреймворки роблять розширювані типи (кастомні фікстури Playwright); розширюють його extends, а type — перетином &.
• Тримаю в голові правило вибору: interface за замовчуванням, type — коли треба щось, чого interface не вміє.

Union і literal types

• Розумію union type (string | number) як «значення одного з кількох типів» і навіщо він для неоднорідних даних.
• Можу пояснити literal type ("passed" | "failed") і чому він рятує від «магічних рядків»: одрук стає помилкою компіляції.

any, unknown, never

• Знаю різницю any vs unknown: any глушить перевірку й «заражає» код далі, а unknown вимагає звузити тип перед використанням — тому саме він пасує до await response.json() і зовнішнього вводу.
• Можу пояснити never як тип без значень і його користь — перевірку на вичерпність (exhaustiveness) switch за union літералів.

strictNullChecks і опціональність

• Розумію, що ? робить поле опціональним і фактично додає undefined до його типу (timeout?: number = number | undefined).
• Можу пояснити ефект strictNullChecks: null/undefined стають окремими типами, і компілятор змушує обробити «порожнечу» перед використанням.
• Знаю, чому оператор ! (non-null assertion) — пастка: він вимикає перевірку компілятора, нічого не перевіряючи в рантаймі, і глушить справжній сигнал null з локатора.

enum проти union літералів

• Можу пояснити, чому enum лишає слід у рантаймі (реальний обʼєкт, а числовий — ще й зворотний мапінг), а union літералів стирається безслідно, і назвати, коли enum усе ж доречний — коли значення треба перебирати в коді як колекцію.