Дебаг JS/TS: console, breakpoints, source maps

Чому «насипати console.log» — слабка стратегія дебагу, і що робити натомість?

console.log показує тільки той зріз стану, який ти вгадав наперед, а кожна нова гіпотеза коштує правки коду й перезапуску. Breakpoint працює інакше: виконання завмирає на рядку, і в цю мить доступний увесь контекст — локальні змінні, аргументи, this, стек викликів, і будь-який вираз можна порахувати в консолі дебагера. Тобто ти не передбачаєш, що вивести, а вже стоїш усередині й дивишся на все одразу. Практичний наслідок — одна пауза замінює десяток циклів «додав лог, перезапустив, прибрав». На співбесіді системна відповідь через breakpoint читається як досвід, а не переказ туторіалу.

Які методи console, крім log, ти реально використовуєш?

Найкорисніші — console.table для масиву об'єктів (виводить його як таблицю з колонками, зручно дивитися на тестові дані чи рядки з API), і console.dir для об'єкта, коли треба саму розкладку властивостей, а не текстове представлення. Для діагностики стану виконання є console.trace — він друкує стек викликів до поточної точки, тобто показує, хто нас сюди покликав. console.count('мітка') рахує, скільки разів код дійшов до рядка — швидкий спосіб зловити зайву ітерацію чи подвійний виклик обробника. Ще console.error і console.warn пишуть у stderr і візуально виділяються, тож у шумному виводі їх видно одразу.

Навіщо писати console.log({ user, token }), а не console.log(user, token)?

Обгортка у фігурні дужки друкує не лише значення, а й імена змінних поряд. Коли в терміналі десяток однотипних логів, голі значення без підпису — це головоломка «а це чиє», яку доводиться розгадувати за позицією. Механізм простий: { user, token } — це скорочений синтаксис об'єкта, тож у виводі буде видно ключ і значення. Практично це економить час на самому читанні логу: ти витрачаєш зусилля на баг, а не на розшифровку власного виводу.

У чому різниця між console.log і console.dir для об'єкта?

console.log намагається показати «людське» представлення, а console.dir завжди друкує об'єкт як дерево властивостей. У браузері різниця принципова: якщо передати DOM-елемент, console.log покаже його як HTML-розмітку, а console.dir — сам JS-об'єкт з його полями й методами. У Node console.dir бере другим аргументом опції, і саме там живе рятівний { depth: null }, який знімає обмеження глибини друку. Коротко: треба поколупати структуру об'єкта — бери dir, треба побачити елемент як розмітку — log.

console.log(obj) показує [Object] замість вмісту — що сталося і як побачити повне?

Це не «даних немає», а обмеження глибини друку: вивід згорнув вкладений об'єкт до заглушки [Object] (масив — до [Array]), бо за замовчуванням він не розкриває структуру глибше певного рівня. Легко переплутати з порожнім об'єктом і піти шукати баг не там. Розкрити можна двома способами: console.dir(obj, { depth: null }) у Node зніме ліміт вкладеності, або JSON.stringify(obj, null, 2) серіалізує все в читабельний рядок. Друге не працює з циклічними посиланнями й губить функції, тож для складних об'єктів надійніший dir.

Що таке breakpoint і які є способи покрокового проходу?

Breakpoint (точка зупину) — позначка на рядку, на якій виконання завмирає й віддає керування тобі; у цей момент видно весь стан і можна рахувати вирази. Далі паузою керуєш кількома командами. Step over виконує поточний рядок і стає на наступний, не заходячи всередину викликаних функцій. Step into навпаки заходить у функцію на поточному рядку, щоб пройти її зсередини. Step out доганяє поточну функцію до кінця й піднімає тебе на рівень вище. Continue біжить далі до наступного breakpoint. Комбінація цих кроків дає точний контроль: пропускаєш нецікаве через over, пірнаєш у підозріле через into.

Коли потрібні умовний breakpoint і logpoint?

Умовний breakpoint зупиняється тільки тоді, коли заданий вираз істинний — це рятує в циклах: дебажиш тисячу елементів, а баг на конкретному, ставиш умову item.id === 42 замість того, щоб сто разів тиснути Continue. Logpoint — це breakpoint, який не зупиняє виконання, а друкує повідомлення; по суті console.log, який не треба вписувати в код і потім не забути прибрати. Обидва економлять найбільше часу саме тому, що прибирають ручну рутину. Logpoint особливо доречний, коли лізти правками в чужий чи згенерований файл не хочеться взагалі.

Що робить інструкція debugger; і чому вона іноді «не зупиняє»?

debugger; — це вставлена прямо в код точка зупину: якщо процес запущено під дебагером, виконання завмре на ній так само, як на breakpoint з поля редактора. Пастка в тому, що без під'єднаного інспектора (звичайний запуск без --inspect) ця інструкція — просто no-op, вона нічого не робить. Тому «debugger; не працює» майже завжди означає, що процес стартував без інспектора, а не що зламалась сама інструкція. Зворотний бік теж болючий: забутий у коді debugger; під час прогону з дебагером підвісить тест намертво.

Що таке JavaScript Debug Terminal у VS Code і чим він зручний для тестів?

Це окремий термінал VS Code, який автоматично під'єднує дебагер до будь-якого Node-процесу, запущеного всередині нього. Зручність у тому, що не треба писати й підтримувати launch.json: відкрив цей термінал, поставив breakpoint у тесті, запустив звичну команду прогону — і зупинка спрацює. Для тестового проєкту це найкоротший шлях до дебагу: команда запуску та сама, що й завжди, а дебагер чіпляється сам. Механізм під ним стандартний — той самий інспектор Node, просто VS Code бере на себе під'єднання.

Що таке інспектор Node.js, на якому порту він працює і що це за протокол?

Інспектор Node.js — це вбудований сервер налагодження: коли Node стартує з прапорцем --inspect, він відкриває його на порту 9229. Спілкування йде за протоколом V8 Inspector — тим самим Chrome DevTools Protocol, яким користуються й DevTools браузера. До цього порту під'єднується клієнт: VS Code або Chrome за адресою chrome://inspect. Розуміти цей шар важливо, бо коли «дебаг не чіпляється», причина майже завжди тут — не той порт, не той процес, або ранер запускає тести в окремому воркері, до якого інспектор головного процесу не дотягується.

У чому різниця між --inspect і --inspect-brk?

Обидва відкривають інспектор, але по-різному стартують виконання. --inspect відкриває порт і одразу біжить далі — якщо баг на самому старті програми, ти просто не встигнеш під'єднатися. --inspect-brk відкриває інспектор і завмирає на першому ж рядку, чекаючи, поки під'єднається дебагер. Друге — саме те, що треба для проблем в ініціалізації або в короткому скрипті, який відпрацьовує за мілісекунди й закінчується раніше, ніж ти встиг щось зробити. Правило просте: баг «на початку» — --inspect-brk, баг «десь у процесі» — --inspect.

Що таке source map і навіщо вона при TypeScript?

Ні браузер, ні Node не виконують TypeScript — його спершу компілюють у JavaScript, тож реально біжить test.js, а пишеш і хочеш дебажити test.ts. Source map (карта коду) — це файл (зазвичай test.js.map) або вбудований коментар, який зіставляє позиції: «рядок такий-то в JS відповідає рядку такому-то в TS». Дебагер читає цю карту й перекладає позиції в обидва боки, тому breakpoint у .ts «прилипає», а зупинка виглядає теж у .ts, хоча під капотом крутиться JS. Без карти breakpoint у TS не мав би куди чіплятися, а стек-трейс помилки показував би номери рядків згенерованого JS, які не збігаються з твоїм джерелом.

У тестовому проєкті source maps треба налаштовувати руками?

Здебільшого ні. Сучасні ранери й швидкі транспілятори — esbuild, tsx, swc — вмикають карти самі, тому в Playwright стек-трейс помилки й breakpoints одразу вказують на .ts без жодного налаштування. Якщо ж компіляція йде класичним tsc, за карти відповідає опція sourceMap: true у tsconfig.json. Практичний наслідок: коли карти «є за замовчуванням», зайве їх чіпати, а от коли breakpoint став сірим (unbound), варто перевірити, чи вони взагалі генеруються й чи не застаріли після зміни збірки.

Що робить прапорець --enable-source-maps у Node?

Він вмикає підтримку карт для стек-трейсів помилок. За замовчуванням, коли Node виконує скомпільований JS і падає, трейс показує рядки саме .js — тобто згенерованого коду, у якому важко орієнтуватися. З --enable-source-maps номери рядків у помилці перекладаються на оригінальний TS. Це різниця між «помилка десь у чужому згенерованому файлі» і «помилка в моєму login.page.ts, рядок 40». Важливо не плутати цей прапорець з breakpoints: карти для дебагера й карти для трейсів — суміжні, але вмикаються різними механізмами.

Чому console.log зі сторінки застосунку не видно в терміналі тесту?

Бо логи тестового коду й логи сторінки — це два різні світи. console.log у твоєму .ts-файлі виконується в Node і йде в термінал, звідки ти запустив прогін. А console.log, який пише сама сторінка (код застосунку в браузері), у Node не тече сам собою — його треба явно перехопити. У Playwright це підписка на подію: page.on('console', msg => ...) для повідомлень і page.on('pageerror', err => ...) для помилок сторінки. Часто це найшвидший спосіб зрозуміти, що застосунок сам лаявся в консоль, а ти цього просто не бачив.

Чим headed-режим і Playwright Inspector допомагають у дебагу тесту?

Багато проблем браузерного тесту не в логіці коду, а у взаємодії з реальною сторінкою: елемент ще не з'явився, перекритий іншим, локатор чіпляє не той вузол — і покроковий дебагер у Node тут мало допомагає, бо треба бачити саму сторінку. Headed-режим (--headed) запускає видиме вікно браузера замість фонового headless. --debug (або змінна PWDEBUG=1) додатково відкриває Playwright Inspector — панель, де тест іде покроково й підсвічує локатори прямо на сторінці. А page.pause(), вставлений у тест, зупиняє прогін у цій точці й дає поклацати локатори вручну, перевіряючи, що саме вони знаходять.

Що таке trace viewer і чому це головний інструмент для «локально зелено, у CI червоно»?

Trace viewer — це post-mortem-дебаг: Playwright записує трасування прогону (снапшоти DOM, усі дії, мережеві запити, консоль, час), і потім ти відкриваєш його як «машину часу» через npx playwright show-trace. Наводишся на будь-яку дію — і бачиш стан сторінки саме в той момент, тобто переграєш впалий тест кадр за кадром. Це розв'язує найболючіший клас проблем AQA: ти не можеш відтворити фейл на своїй машині, але маєш повний запис того, що сталося на агенті — видно, що кнопку перекрив банер, що запит повернув 500 або що сторінка ще крутила спінер. Записується трейс за конфігом (trace: 'on-first-retry' — типовий вибір: писати лише при першому перезапуску), і саме тому в CI його варто вмикати завжди.

Тест зелений локально, червоний у CI — як системно шукатимеш причину?

Спершу класифікую, де взагалі проблема: у логіці коду тесту, у взаємодії з UI чи в самому середовищі. Якщо баг у логіці — ставлю breakpoint у VS Code і дивлюся стан у точці паузи. Якщо у взаємодії зі сторінкою — запускаю headed з Inspector або ставлю page.pause(), щоб побачити реальну сторінку. Для суто CI-фейлу головний доказ — trace viewer: він показує чужий агент зсередини, тож не треба наосліп перезапускати джоб. Головна дисципліна — не заявляти причину без доказу: не «схоже на флак», а «на трейсі видно, що кнопку перекрив cookie-банер, клік пішов не туди».

Три кейси з робочого життя AQA: як за симптомом фейлу обрати інструмент дебагу, як витягти читабельний стан із console, коли log замало, і як побачити те, що застосунок ховає в браузерній консолі й у CI-прогоні. Скрізь — що дивитися і чому.

Кейс 1. Матриця «симптом → інструмент»: з чого починати

Найгірше — гатити наосліп: додати console.log, перезапустити, прибрати, додати ще. Спершу класифікуй, де взагалі проблема, і бери відповідний інструмент. Ось як це лягає в таблицю рішень.

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

• Спершу питання «де проблема», а не «який рядок додати». Одна класифікація економить години: покроковий дебагер безсилий проти перекритої кнопки, а trace viewer нічого не скаже про логічну помилку в чистій функції.
• undefined в асерті — класичний загублений await. Breakpoint на рядку асерту й погляд на значення до порівняння швидко покаже, що проміс не дочекалися, а не що дані «зникли».
• «Зелено локально» майже ніколи не дебажиться локально. Відтворити фейл на своїй машині не вийде за побудовою — потрібен запис того, що сталося на агенті, тобто трейс.

Кейс 2. Коли console.log замало: table, dir, count

Тест перевіряє набір користувачів з API, а log вивалює нечитабельну кашу, і вкладені поля згорнуті в [Object]. Три методи роблять вивід придатним для читання.

const users = [
  { id: 1, name: 'Ada', role: 'admin', profile: { city: 'Kyiv' } },
  { id: 2, name: 'Bob', role: 'user', profile: { city: 'Lviv' } },
];

// таблиця з потрібними колонками — не тонемо в зайвих полях
console.table(users, ['name', 'role']);

// повний вміст вкладеного об'єкта: log обрізав би profile до [Object]
console.dir(users[0], { depth: null });

А ось діагностика «скільки разів код сюди дійшов» — коли є підозра на подвійний виклик обробника чи зайву ітерацію:

function handleResponse(res: unknown) {
  console.count('handleResponse'); // handleResponse: 1, handleResponse: 2 ...
  // ...
}

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

• [Object] у виводі — це ліміт глибини, а не порожнеча. Легко переплутати з «даних немає» й піти шукати баг не там; console.dir(obj, { depth: null }) або JSON.stringify(obj, null, 2) розкриють вміст.
• console.table економить саме читання. Для масиву об'єктів колонки з підписами швидші за очі, ніж потік однотипних рядків; другий аргумент відсіює зайві поля.
• console.count ловить кратність. Якщо лічильник росте вдвічі швидше за очікуване — знайдено подвійну підписку чи зайвий рендер, і це видно без жодного breakpoint.
• Дисципліна: усе це — тимчасовий дебаг. Перед комітом його прибирають, інакше вивід прогону засмічується й реальний сигнал губиться серед сотні рядків.

Кейс 3. Playwright: перехопити консоль сторінки, зупинитись, лишити трейс

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

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

test('дашборд показує нову фічу', async ({ page }) => {
  // логи й помилки СТОРІНКИ течуть у термінал поряд з логами тесту
  page.on('console', (msg) => console.log(`[browser] ${msg.type()}: ${msg.text()}`));
  page.on('pageerror', (err) => console.log(`[browser error] ${err.message}`));

  await page.goto('https://app.example.com/dashboard');

  // зупинка для ручного клацання локаторів; прибрати перед комітом
  // await page.pause();

  await expect(page.getByTestId('new-feature-button')).toBeVisible();
});

Часто вже перший рядок [browser error] показує, що на сторінці впав JS і кнопка просто не відмалювалась — тоді баг у застосунку, а не в локаторі. Якщо ж треба поколупати локатори руками, розкоментовуємо page.pause() і запускаємо в headed:

npx playwright test --headed --debug

Для CI-фейлу, який не відтворюється локально, головне — не логи, а запис. Вмикаємо трейс у конфігу й потім переграємо прогін:

// playwright.config.ts
export default {
  use: { trace: 'on-first-retry' }, // писати трейс лише при першому перезапуску
};

npx playwright show-trace trace.zip

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

• Логи тесту й логи сторінки — різні світи. console.log у .ts іде в Node, а повідомлення сторінки без page.on('console', ...) у термінал не потраплять; половина «мовчазних» фейлів насправді криклива, просто крик не перехопили.
• page.pause() показує реальну сторінку. Inspector підсвічує, що саме знаходить локатор — часто виявляється, що він чіпляє не той вузол або елемент ще перекритий банером.
• trace: 'on-first-retry' — розумний компроміс. Писати трейс на кожен тест дорого, а на першому ретраї — рівно там, де фейл уже стався; у trace viewer видно снапшот DOM, мережу й консоль у момент падіння.
• Трейс — це доказ замість «здається». Замість наосліп перезапускати джоб, наводишся на впалу дію й бачиш: кнопку перекрив cookie-банер, запит повернув 500, сторінка ще крутила спінер.

console — вивід під контролем

• Розумію, чому console.log показує лише заздалегідь обраний зріз стану й вимагає перезапуску на кожну правку.
• Можу пояснити різницю console.log vs console.dir для DOM-елемента: розмітка проти дерева властивостей.
• Знаю, що [Object]/[Array] у виводі — це ліміт глибини друку, а не порожнеча; розкриваю через console.dir(obj, { depth: null }) чи JSON.stringify.
• Знаю призначення console.table (масив об'єктів колонками), console.trace (стек викликів), console.count (лічильник влучань у рядок).

Breakpoints і покрокове виконання

• Можу пояснити, чому breakpoint дає весь стан у точці паузи без правок коду, а console.log — ні.
• Знаю різницю Step over / Step into / Step out і коли яку команду тиснути.
• Розумію, навіщо умовний breakpoint у циклі (item.id === 42) і чим logpoint кращий за вписаний у код console.log.
• Знаю, що debugger; без під'єднаного інспектора — no-op, а забутий у коді під дебагером підвісить тест.
• Розумію, чим зручний JavaScript Debug Terminal у VS Code: чіпляє дебагер до Node-процесу без launch.json.

Node-інспектор під капотом

• Знаю, що під VS Code працює інспектор Node.js на порту 9229 за протоколом V8 Inspector (він же Chrome DevTools Protocol).
• Можу пояснити різницю --inspect (біжить одразу) vs --inspect-brk (завмирає на першому рядку до під'єднання).

Source maps: TS vs JS

• Розумію, що виконується скомпільований JS, а пишемо й дебажимо TS, і зв'язок між ними дає source map.
• Знаю, що ранери (esbuild, tsx, swc) зазвичай вмикають карти самі, а класичний tsc — через sourceMap: true.
• Розумію, що --enable-source-maps лагодить саме стек-трейси помилок у Node, показуючи рядки TS замість JS.
• Знаю, що сірий (unbound) breakpoint — сигнал відсутньої/застарілої карти або дебагу не того файлу.

Логи в тестах

• Розумію, що логи тестового коду (Node → термінал) і логи сторінки (браузер) — різні світи.
• Знаю, що логи сторінки треба перехоплювати явно: page.on('console', ...) і page.on('pageerror', ...).

Дебаг браузерного тесту: headed і trace viewer

• Знаю, що дає headed-режим (--headed), --debug/PWDEBUG=1 (Playwright Inspector) і page.pause().
• Можу пояснити, що trace viewer — post-mortem «машина часу» (снапшоти DOM, дії, мережа, консоль), і чому в CI трейс вмикають завжди.