Змінні, типи даних і приведення типів

Чим відрізняються var, let і const?

Відмінність поведінкова, а не стильова. var має функціональну область видимості (function scope) і «піднімається» на початок функції через hoisting, тож звернення до неї до рядка оголошення повертає undefined замість помилки. let і const живуть лише в межах свого блоку { } і кидають ReferenceError, якщо їх торкнутися до оголошення. Ще одна різниця: const не дозволяє переприсвоїти змінну повторно, let дозволяє, var теж дозволяє. Практичне правило для тестового коду просте: типово const, let — тільки коли значення справді доведеться замінити, var — не використовуємо взагалі.

Що таке hoisting і temporal dead zone?

Hoisting — це те, що оголошення змінних і функцій обробляються JS-рушієм ще до виконання коду, ніби «підняті» вгору області. Для var це означає, що змінна існує з самого початку функції зі значенням undefined, тому звернення до неї до присвоєння не падає, а мовчки дає undefined. Для let і const оголошення теж «підняте», але доступ до змінної заблокований від початку блоку до рядка оголошення — цей проміжок і називають мертвою зоною (temporal dead zone, TDZ). Спроба прочитати змінну в TDZ кидає ReferenceError. Це навмисна страховка: код падає одразу й голосно, а не працює далі з випадковим undefined.

const робить обʼєкт незмінним?

Ні, і це найпоширеніше непорозуміння. const захищає лише привʼязку імені до значення (binding) — не дозволяє присвоїти змінній інше значення. Але якщо значення — обʼєкт, його внутрішній вміст мутувати можна: const config = {} не заважає написати config.timeout = 5000. Заборонене лише повне переприсвоєння на кшталт config = {}, яке кине TypeError. Якщо треба заморозити саме вміст, це вже інші інструменти — Object.freeze або дисципліна команди, а не ключове слово const.

Які примітивні типи є в JavaScript і чим примітив відрізняється від обʼєкта?

Примітивів сім: string, number, bigint, boolean, undefined, symbol і null. Ключова властивість примітива — незмінність (immutability): будь-яка операція над рядком чи числом повертає нову величину, а не редагує стару на місці. Примітиви зберігаються прямо в змінній і копіюються за значенням. Усе інше — обʼєкти: літерали {}, масиви, функції, Date, Map, Set. Обʼєкт лежить у купі (heap), а змінна тримає лише посилання (reference) на нього, тому обʼєкти копіюються за посиланням. Ця межа визначає геть усе подальше: як значення копіюються при присвоєнні й передачі в функцію та як порівнюються між собою.

Чому два обʼєкти з однаковим вмістом не рівні, а два однакові числа — рівні?

Бо порівняння обʼєктів іде за посиланням, а не за вмістом. Числа й інші примітиви зберігаються в змінній безпосередньо, тож 42 і його копія — це два незалежні значення, і === бачить їх рівними. Обʼєкт же представлений посиланням на місце в купі; { a: 1 } === { a: 1 } дає false, бо це два різні місця в памʼяті, хоч поля й збігаються. Для QA це щоденний факт: асерт на рівність обʼєктів через === перевіряє тотожність, а не однаковість, тому для порівняння структур беруть глибоке порівняння (toEqual у більшості фреймворків), а не toBe.

Що поверне typeof null і чому саме так?

typeof null повертає рядок "object" — це давня вада самого JavaScript, закладена в першій версії й залишена назавжди заради зворотної сумісності. null не є обʼєктом, просто оператор typeof на ньому «бреше». Через це перевіряти значення на null через typeof не можна: правильний спосіб — пряме порівняння value === null. Варто мати напоготові і сам факт, і причину, і надійну альтернативу.

Як надійно визначити, що значення — масив?

Через typeof — ніяк, бо масив технічно є обʼєктом, і typeof [1, 2, 3] дає те саме "object", що й звичайний літерал. Для цього існує окремий метод Array.isArray(value), який повертає true тільки для масивів. На практиці для QA це перша лінія оборони, коли з API приходить поле невідомої форми: перш ніж викликати на ньому методи масиву чи звертатися до властивостей обʼєкта, варто перевірити фактичну форму через Array.isArray і typeof, інакше легко впертися в TypeError на несподіваному типі.

Чим null відрізняється від undefined?

Обидва означають «значення немає», але семантика протилежна за походженням. undefined — це «система не задала значення»: змінну оголошено без присвоєння, властивості в обʼєкті немає, функція нічого не повернула, аргумент не передали. null — це «розробник свідомо поставив порожнє»: хтось навмисно написав null, щоб позначити відсутність. При нестрогому порівнянні null == undefined дає true (вони рівні лише одне одному), а при строгому null === undefined — false, бо це різні типи. Для QA різниця не теоретична: «поля немає» і «поле дорівнює null» — два різні контракти API, які й перевіряти треба по-різному.

Як поводяться null і undefined при JSON.stringify?

По-різному, і це щоденно спливає в API-тестуванні. Поле зі значенням undefined при серіалізації зникає з JSON повністю, а поле з null лишається у вигляді null: JSON.stringify({ a: undefined, b: null }) дає рядок, де є тільки b. Практичний наслідок: щоб перевірити відсутність поля, питають "a" in body === false, а щоб перевірити явний null — питають body.a === null. Плутати ці дві перевірки означає писати тест, який пропускає реальну розбіжність контракту.

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

=== (строга рівність, strict equality) порівнює без жодного приведення: якщо типи операндів різні — результат одразу false. == (нестрога рівність, loose equality) спершу приводить операнди до спільного типу за набором історичних правил, і лише потім порівнює. Саме це приховане приведення (coercion) породжує результати, які виглядають абсурдно: "200" == 200 дає true, 0 == "" дає true, false == 0 дає true. Висновок для тестового коду однозначний: завжди ===. Єдиний прагматичний виняток — навмисна перевірка value == null, що одним порівнянням ловить і null, і undefined.

Наведіть приклад, де == небезпечний саме в автотесті.

Класика — прихований баг серіалізації. Уявіть, що сервер через помилку повертає статус як рядок "404" замість числа 404. Тест написаний як expect(status == 404) — оператор == приведе рядок до числа, порівняння дасть true, і тест буде зелений, хоча контракт зламано. Зі === типи різні, порівняння дає false, і тест чесно червоніє, вказуючи на реальну проблему. Тому == у продакшн-тесті — це запрошення до фальшиво-зелених результатів; недарма лінтер із правилом eqeqeq забороняє його за замовчуванням.

Перелічіть хибні (falsy) значення в JavaScript.

Їх вісім: false, 0, -0, 0n (нуль типу BigInt), "" (порожній рядок), null, undefined і NaN. Усе, чого немає в цьому списку, у булевому контексті приводиться до true. Найпідступніше для тестів те, що істинними є "0" (рядок з нулем), "false" (теж рядок), [] (порожній масив) і {} (порожній обʼєкт) — інтуїція часто підказує протилежне. Тому питання «чи істинний порожній масив» на співбесіді перевіряє, чи не сплутає кандидат [] з «порожній = хибний».

Чому перевірка if (response.body.count) небезпечна?

Бо вона перевіряє істинність значення, а не його наявність, і легітимний нуль тихо провалюється. Якщо поле count законно може дорівнювати 0 (нуль замовлень — валідна відповідь), то if (response.body.count) вважатиме його відсутнім, бо 0 — хибне значення. Те саме станеться з порожнім рядком "" як валідним значенням поля. Правильно питати про наявність явно: if (response.body.count !== undefined) або "count" in response.body. А для «взяти значення, якщо воно задане» беруть оператор ?? (nullish coalescing), який реагує тільки на null і undefined, а не на всі хибні значення.

Чому NaN === NaN дає false і як тоді перевіряти на NaN?

NaN (Not-a-Number) — єдине значення мови, яке не дорівнює саме собі: і NaN === NaN, і NaN == NaN дають false. Це закладено в стандарті чисел з плаваючою комою, тож звичайним порівнянням NaN не зловити. Перевіряти треба через Number.isNaN(value), який повертає true, лише коли значення справді є NaN. Типовий для QA сценарій: тест дістає число з тексту сторінки через Number(await locator.textContent()), і якщо в елементі опинився не той текст, результат — NaN. Перевірка Number.isNaN(parsed) перед асертом дає зрозумілу помилку одразу, а не загадковий провал десь далі по коду.

Чим isNaN відрізняється від Number.isNaN?

Різниця в тому, чи функція приводить аргумент до числа. Глобальна isNaN спершу приводить аргумент, а вже потім перевіряє, тому вона «бреше»: isNaN("abc") повертає true, бо рядок "abc" при приведенні перетворюється на NaN, хоча сам по собі він — не NaN. Number.isNaN (з ES2015) нічого не приводить і повертає true, тільки якщо переданий аргумент уже є NaN — Number.isNaN("abc") дає false. Правило для тестів: завжди Number.isNaN, бо глобальна версія дасть хибно-позитивний результат на будь-якому нечисловому вводі.

Що станеться, якщо передати обʼєкт у функцію і змінити його поле?

Зміна буде видима зовні, бо обʼєкти передаються за посиланням. Точніше — копіюється саме посилання, тож і викликач, і функція дивляться на той самий обʼєкт у купі; мутація поля всередині функції змінює оригінал. Примітив натомість передається за значенням: функція отримує копію, і присвоєння всередині оригіналу не торкнеться. Цю модель називають call by sharing. Слабкий кандидат каже «нічого, це ж копія»; сильний одразу згадує ризик випадково зіпсувати спільні тестові дані через таку мутацію.

Чому спільний фікстурний обʼєкт спричиняє «плаваючі» падіння тестів?

Бо один тест може мутувати спільний обʼєкт, а наслідки прилетять іншому. Уявіть базовий обʼєкт користувача { role: "admin" }, який тест 1 «підправляє під себе» на role: "guest"; тест 2 очікує admin і падає, хоча його власний код правильний. Симптом упізнаваний: тест червоніє залежно від порядку запуску або «через раз» при паралельному прогоні — це територія флакі-тестів. Причина в тому, що присвоєння const b = a для обʼєкта копіює лише посилання, тож a і b стають двома іменами одного обʼєкта. Лікування — не мутувати спільні дані, а працювати з копією.

Як безпечно скопіювати обʼєкт із тестовими даними?

Залежно від того, чи він вкладений. Для плоского обʼєкта вистачає поверхневої копії через spread — { ...baseUser } створює новий обʼєкт із тими самими значеннями полів. Але spread копіює лише верхній рівень: якщо всередині є вкладені обʼєкти чи масиви, вони й далі спільні за посиланням, і мутація вкладеного поля зачепить оригінал. Для таких випадків потрібна глибока копія — structuredClone(baseUser) створює повністю незалежну структуру. Правило для фікстур: якщо дані містять вкладеність, поверхнева копія оманлива, бери глибоку.

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

Кейс 1. == маскує баг серіалізації статусу

Бекенд через регресію почав повертати HTTP-статус як рядок "200" замість числа 200. Функціонально відповідь та сама, але контракт зламано — і саме такі речі має ловити тест. Подивимось, як вибір оператора рівності вирішує, помітимо ми регресію чи ні.

// поле, яке насправді прийшло від зламаного бекенду
const status = "200"; // рядок, а мав бути number

status == 200;  // true  ← приведення "200" → 200, баг сховано
status === 200; // false ← типи різні, баг видно

У тесті це виглядає так:

import { test, expect } from '@playwright/test';

test('статус створення ресурсу', async ({ request }) => {
  const res = await request.post('https://api.example.com/orders', {
    data: { item: 'sku-1', qty: 1 },
  });

  const status = res.status(); // Playwright віддає number — це добре
  // але якщо код дістає статус із тіла відповіді, тип уже не гарантований
  const reported = (await res.json()).status; // тут може бути "201"

  // Погано: приховане приведення зробить зелено навіть на рядку
  // expect(reported == 201).toBeTruthy();

  // Добре: строге порівняння впаде на розбіжності типів
  expect(reported).toBe(201);
});

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

• == приводить операнди до спільного типу перед порівнянням. "200" == 200 спершу перетворює рядок на число, тож розбіжність типів зникає ще до порівняння — і баг серіалізації лишається непоміченим.
• === не приводить нічого. Різні типи — одразу false, тест чесно червоніє й показує реальну проблему контракту.
• toBe у Playwright/Jest — це === під капотом. Тому асерт expect(reported).toBe(201) автоматично строгий; писати ручні порівняння через == немає причини.
• Увімкніть eqeqeq в ESLint. Правило забороняє ==/!= на рівні лінтера, тож фальшиво-зелений асерт не доживе навіть до код-рев'ю.

Кейс 2. Хибний нуль провалює перевірку наявності поля

API повертає лічильник замовлень користувача. Нуль замовлень — цілком валідна відповідь, але наївна перевірка «чи є поле» через істинність тихо його відкидає, бо 0 — хибне значення.

// відповідь для нового користувача — нуль замовлень, це легітимно
const body = { userId: 7, count: 0 };

// Погано: 0 — falsy, тож перевірка вважає поле відсутнім
if (body.count) {
  // сюди не зайдемо навіть при валідному нулі
}

// Добре: питаємо саме про наявність, а не про істинність
if (body.count !== undefined) {
  // спрацює і для 0, і для будь-якого числа
}

У тесті пастка виглядає так:

import { test, expect } from '@playwright/test';

test('поле count присутнє навіть при нулі замовлень', async ({ request }) => {
  const res = await request.get('https://api.example.com/users/7/stats');
  const body = await res.json();

  // Погано: || 'немає' підмінить легітимний 0 на рядок
  // const shown = body.count || 'немає';

  // Добре: ?? реагує лише на null/undefined, нуль лишається нулем
  const shown = body.count ?? 'немає';

  expect('count' in body).toBe(true);        // поле в контракті є
  expect(typeof body.count).toBe('number');  // і саме число
  expect(shown).toBe(0);                      // нуль не підмінився
});

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

• 0, "" і NaN — хибні, але валідні дані. Перевірка через if (value) чи value || fallback відкидає їх разом зі справжньою відсутністю, тож нуль замовлень або порожнє імʼя мовчки губляться.
• Наявність поля перевіряють явно. "count" in body або body.count !== undefined відповідають на питання «поле є?», не плутаючи його з питанням «поле істинне?».
• ?? замість || для дефолтів. Оператор ?? (nullish coalescing) підставляє запасне значення лише на null/undefined, а || — на будь-якому хибному, тому й підмінює легітимний 0.

Кейс 3. Мутація спільної фікстури = флак, залежний від порядку

Класична причина «зелено поодинці, червоно в наборі»: тести ділять один обʼєкт із даними, а присвоєння його не копіює — воно копіює посилання. Один тест мутує обʼєкт «під себе», сусідній падає.

// спільна фікстура на весь файл
const baseUser = { email: 'qa@example.com', role: 'admin', profile: { theme: 'dark' } };

// тест 1: думає, що взяв копію, а взяв друге імʼя того самого обʼєкта
const u1 = baseUser;
u1.role = 'guest'; // зіпсував baseUser для всіх наступних тестів

// тест 2: очікує admin і падає, хоча власний код правильний
baseUser.role === 'admin'; // false — прилетіло від тесту 1

Симптом — падіння залежить від порядку запуску або зникає/зʼявляється при паралельному прогоні. Лікування — працювати з копією, і тут важливо не сплутати поверхневу з глибокою:

import { test, expect } from '@playwright/test';

const baseUser = { email: 'qa@example.com', role: 'admin', profile: { theme: 'dark' } };

test('поверхнева копія рятує плоскі поля', async () => {
  const user = { ...baseUser };   // spread — новий обʼєкт верхнього рівня
  user.role = 'guest';            // baseUser.role лишається 'admin'
  expect(baseUser.role).toBe('admin');
});

test('але вкладене поле в spread усе ще спільне', async () => {
  const user = { ...baseUser };
  user.profile.theme = 'light';   // profile — те саме посилання!
  // baseUser.profile.theme теж став 'light' — оце і є пастка
  expect(baseUser.profile.theme).toBe('light'); // на жаль, true

  // Правильно для вкладених структур — глибока копія:
  const safe = structuredClone(baseUser);
  safe.profile.theme = 'dark';
  expect(baseUser.profile.theme).not.toBe('dark'); // тепер незалежні
});

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

• Присвоєння обʼєкта не копіює обʼєкт. const u1 = baseUser дає друге імʼя тієї самої структури; будь-яка мутація через u1 видима через baseUser.
• Spread копіює лише верхній рівень. { ...baseUser } захищає плоскі поля, але вкладений profile лишається спільним за посиланням — типове джерело «непояснюваного» флаку.
• structuredClone дає повну ізоляцію. Для фікстур із вкладеністю це надійний вибір; поверхневої копії досить лише для гарантовано плоских даних.
• Найкраще — фабрика фікстур. Функція, що повертає свіжий обʼєкт на кожен виклик (makeUser()), узагалі знімає питання спільного стану, бо тести не ділять один екземпляр.

Оголошення змінних

• Можу пояснити різницю області видимості: var — функціональна, let/const — блокова, до { } включно.
• Розумію hoisting: var до оголошення дає undefined, а let/const кидають ReferenceError у мертвій зоні (TDZ).
• Знаю, що const фіксує лише привʼязку імені, а не вміст обʼєкта — const obj = {} дозволяє obj.x = 1, але не obj = {}.

Примітиви й обʼєкти

• Можу перелічити сім примітивів: string, number, bigint, boolean, undefined, symbol, null.
• Розумію, що примітиви незмінні й копіюються за значенням, а обʼєкти лежать у купі й копіюються за посиланням.

typeof і перевірка типів

• Памʼятаю вісім можливих результатів typeof і три «сюрпризи»: null, масив і функція.
• Можу пояснити, чому typeof null === "object" — історична вада мови, і що надійна перевірка на null це value === null.
• Знаю, що масив від обʼєкта typeof не відрізняє, тож перевіряю через Array.isArray(value).

null проти undefined

• Розрізняю семантику: undefined — не задано системою, null — явно порожньо за рішенням розробника.
• Можу пояснити поведінку JSON.stringify: undefined-поле зникає з JSON, null лишається.

Рівність і приведення типів

• Можу пояснити різницю == vs ===: нестрога рівність приводить типи, строга — ні; приклад status == 200 проходить і для рядка "200".
• Тримаю висновок: у тестах завжди ===; єдиний виправданий виняток — value == null.

truthy і falsy

• Можу перелічити вісім хибних значень: false, 0, -0, 0n, "", null, undefined, NaN.
• Знаю пастку: "0", "false", [] і {} — істинні, хоч інтуїція підказує протилежне.
• Розумію, чому if (body.count) небезпечна, коли 0 — валідне значення, і замінюю її на !== undefined або in.

NaN

• Можу пояснити, чому NaN !== NaN, і що перевіряти на NaN треба лише через Number.isNaN.
• Знаю різницю isNaN vs Number.isNaN: глобальна приводить аргумент і дає хибний true на "abc", а Number.isNaN — ні.

Передача за значенням і за посиланням

• Можу пояснити call by sharing: примітив у функцію йде копією, обʼєкт — посиланням, тож його мутація видима зовні.
• Розумію, чому const b = a для обʼєкта дає друге імʼя того самого обʼєкта, а не незалежну копію.
• Знаю різницю копій: spread { ...obj } — поверхнева (плоскі дані), structuredClone — глибока (вкладені структури).