Що таке тест і навіщо він потрібен

Claude Code змінив код і написав: "Тести пройшли". За цією короткою фразою стоять файли з перевірками, команда запуску і конкретні результати. Почнемо з того, яке буває тестування і що можна перевірити вручну, далі розберемо автоматичний тест і сенс його результату.

Для цього вистачить маленького прикладу з нарахуванням очок. Знати тестові бібліотеки заздалегідь не потрібно. Спершу пройдемо сценарій вручну, потім сформулюємо очікування для автотестів і розберемо звіт про їхнє виконання.

Яке буває тестування

Тестування допомагає з'ясувати, як поводиться програма, чи відповідає вона вимогам і де виникають проблеми. Наприклад, чи правильно нараховуються очки, чи можна надіслати заявку з порожнім полем, чи зрозуміле повідомлення про помилку. Для цього добирають умови перевірки, виконують дії і вивчають результат.

Поділити тестування можна за різними ознаками. Почнемо з того, хто виконує дії і перевіряє результат:

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

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

Автоматизація не скасовує участі людини. Все одно потрібно вибрати корисні сценарії, визначити очікування і розібратися в знайдених розбіжностях. Просто повторювану частину роботи виконує програма.

Що таке ручне тестування

Під час ручного тестування ви самі виконуєте дії і дивитеся, чи відповідає результат очікуванню. Для цього не обов'язково писати код тесту. потрібні зрозумілі умови і запитання, на яке ви хочете відповісти.

Припустімо, у навчальному порталі за кожен збіг належить 10 очок, тобто за три - 30. Перевірити нарахування вручну можна так:

1. відкрити потрібну версію порталу і підготувати користувача з нульовим балансом, якому ще не нараховували нагороду;
2. підготувати заявку з трьома збігами і надіслати її один раз;
3. подивитися на баланс після відправлення: очікується 30 очок;
4. записати фактичний результат. Якщо вийшло інше число, зберегти кроки і, за потреби, знімок екрана.

Початковий баланс тут важливий. Якщо на ньому вже було 20 очок, після нарахування ви очікуєте 50, а не 30. Без вихідних умов легко сприйняти правильний результат як помилку або навпаки.

Результат перевірки зручно записати коротко: "Баланс до відправлення 0, три збіги, одне відправлення, очікувалося 30, отримано 3". За таким записом інша людина або Claude Code зрозуміє, що потрібно відтворити. Фраза "очки працюють дивно" цього не пояснює.

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

Інструменти при цьому цілком доречні. Можна відкрити консоль браузера, подивитися відповідь сервера, зробити знімок екрана або вести список перевірок. Слово "ручне" означає, що перевіркою керує і результат оцінює людина, а не що вона працює без інструментів.

Ручна перевірка зручна, коли потрібно дослідити нову поведінку або оцінити, чи зрозумілий інтерфейс. Автоматична корисна для багаторазового повторення вже описаних дій і порівнянь. Це не жорсткий поділ на "інтерфейс тільки руками, розрахунки тільки кодом": дії в браузері теж можна автоматизувати, а розрахунок можна перевірити вручну.

Коли ви натискаєте кнопку запуску автотестів, це ще не ручне тестування: самі перевірки після запуску виконує програма. А якщо Claude Code склав вам список кроків, за яким ви самі пройшли портал і оцінили результат, перевірка лишається ручною. Агент допоміг її підготувати.

Що таке автоматичний тест

Уявіть, що ви перевіряєте калькулятор. Вводите 2 + 2, заздалегідь очікуєте 4 і порівнюєте число на екрані з цим очікуванням. Якщо бачите 5, зрозуміло, що для цього прикладу результат неправильний. Ви знаєте правильну відповідь незалежно від того, що показав калькулятор.

Автоматичний тест робить схожу роботу програмно. Це невелика програма, яка задає вихідні умови, виконує дію і перевіряє результат. Замість людини порівняння виконує код. Далі називатимемо такий автоматичний тест просто тестом, так коротше.

Повернімося до порталу з нагородами: один збіг приносить 10 очок, за три належить 30. Перевірку можна записати словами:

1. підготувати кількість збігів: 3;
2. виконати розрахунок нагороди;
3. перевірити, що розмір нагороди дорівнює 30.

Ось це й стане одним тестом. У ньому є заздалегідь відомий приклад і очікувана відповідь. Правило "10 очок за збіг" стосується нашого навчального порталу; в іншому застосунку воно може бути іншим.

Тест сам не вигадує, скільки очок належить користувачеві. Хтось має взяти правило з вимог і записати очікування. Це може зробити розробник або Claude Code за вашим дорученням, але сенс очікування все одно потрібно звірити із завданням.

Навіщо повторювати перевірку

Один раз перевірити нарахування вручну цілком зручно. Проблема з'являється пізніше: ви додали новий вид нагороди, змінили обробку заявки або попросили агента спростити функцію. Після кожної такої правки виникає те саме питання: три збіги й досі дають 30?

Можна щоразу заново готувати заявку, виконувати дії і дивитися результат. А можна записати цю перевірку в код і запускати її знову. За однакових підготовлених умов тест повторить задані дії і порівняння. Без нового пояснення, куди натискати і що вважати правильним.

Що більший проєкт, то більше таких правил. Нульова заявка не має додавати очки; повторну заявку не можна враховувати двічі; список нагород повинен мати певний порядок. Перевірки можна запускати разом і бачити, яке з очікувань перестало виконуватися після зміни.

У цьому користь автоматизації: повторна перевірка вже описаної поведінки потребує менше ручної роботи. Написання тестів теж забирає час (і коли змінюються вимоги, їх доводиться переглядати). Але для правил, до яких ви постійно повертаєтеся, ця робота окупається повторними запусками.

Де лежать тести

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

reward-example/
├── package.json
└── src/
    ├── reward-flow.js
    └── reward-flow.test.js

У reward-flow.js лежить розрахунок нагороди. У reward-flow.test.js лежить код, який викликає цей розрахунок і перевіряє відповідь. Файл package.json описує налаштування проєкту і команди, зокрема й команду тестів.

Частина імені .test.js допомагає впізнати файл перевірки. Це домовленість, яку підтримують інструменти тестування, а не окреме правило мови JavaScript. В інших проєктах трапляються інші імена або окрема тека tests/. Один файл може містити кілька тестів; окремий тестовий файл поряд з кожним вихідником не обов'язковий.

Якщо Claude Code працює в незнайомому проєкті, попросіть спершу знайти наявний тест нарахування і показати його шлях. Так ви зможете зіставити перевірку з потрібною поведінкою, навіть якщо поки не орієнтуєтеся в усіх теках.

Як перетворити намір на перевірку

Прохання "полагодь нарахування і перевір тестами" лишає агентові одразу два питання: що вважати правильним нарахуванням і чим підтвердити результат. Краще почати з поведінки, яку ви хочете отримати. Наприклад: "За кожен збіг належить 10 очок. Якщо збігів три, нагорода має становити 30".

Такий намір можна перетворити на перевірку без жодного рядка коду. Опишіть три речі, і цього вистачить:

Це можна прочитати однією фразою: "Якщо отримано три збіги, то розрахунок нагороди має дати 30 очок". Тут достатньо відомостей, щоб обговорити сенс тесту. Яким кодом оформити перевірку в цьому проєкті, розбереться агент.

Важливо вибрати, що саме ви хочете підтвердити. "Розрахована нагорода 30" і "на балансі користувача стало 30" - різні очікування. Для другого потрібні початковий баланс і дія нарахування, як у ручній перевірці вище. Тому слова "перевір очки" краще замінити точним спостереженням.

Далі подумайте про сусідні ситуації. Для нашого правила достатньо почати з невеликої таблиці:

Не потрібно вигадувати десятки випадків одразу. Почніть з проблемного сценарію і кількох сусідніх, яких могла торкнутися правка. Якщо незрозуміло, що має відбуватися, напр. з повторною заявкою, спершу уточніть правило. Агент може запропонувати варіант, але це ще не узгоджене очікування.

Як доручити перевірку Claude Code

Коли очікувану поведінку сформульовано, можна організувати роботу навколо неї. Спочатку агент з'ясовує, які перевірки вже є в проєкті, потім співвідносить їх з вашими сценаріями. Потрібна перевірка може вже існувати: тоді важливо виконати її і прочитати результат. А якщо її немає, агентові знадобиться додати тест.

Перше доручення може мати такий вигляд:

Потрібно виправити розрахунок нагороди.
Правило: за кожен збіг нараховується 10 очок.
Випадки для перевірки: 3 збіги дають 30 очок,
0 дають 0, 5 дають 50.

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

Прочитайте відповідь як опис майбутнього результату. Чи в усіх випадках числа взято з вашого правила? Перевіряється саме розмір нагороди чи щось інше? Чи немає пропозиції змінити саме правило, щоб до нього підійшла поточна поведінка? На цьому кроці ви уточнюєте завдання, і для цього не потрібно читати реалізацію тесту.

Після уточнення сценаріїв дайте доручення виконати роботу:

Виправ розрахунок за обговореним правилом.
Додай відсутні перевірки узгоджених випадків,
використовуючи заведені в проєкті інструменти.
Наявні очікування не змінюй заради успішного прогону.
Якщо вважаєш очікування хибним, спершу поясни чому.

Запусти потрібні тести за інструкціями проєкту.
Покажи команду, робочу теку і фактичний вивід.
Для кожного з трьох випадків вкажи, який тест його перевіряв
і як він завершився. Пропуски і незапущені перевірки
перелічи окремо.

Команду запуску агент знаходить у документації і налаштуваннях проєкту. У JavaScript-проєкті це часто npm test: npm виконує команду з поля scripts.test файлу package.json. За цим іменем може стояти різний набір перевірок. Ваше завдання - переконатися, що в запуск потрапили потрібні сценарії.

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

У відповіді шукайте зв'язок "наш сценарій → конкретний тест → результат". Якщо з трьох обговорених випадків виконано лише один, поки підтверджено тільки його. Навіть якщо підсумковий рядок зелений.

Як читати результат

Нижче показано реальний запуск одного навчального тесту на Node.js 20.18.0 і npm 10.8.2. Він перевіряє тільки розрахунок нагороди за три збіги, а не весь запропонований вище набір сценаріїв. Щоб легше читалося, прибрано рядки часу і службову обгортку звіту:

> reward-example@1.0.0 test
> node --test --test-reporter=tap

# Subtest: three matches give 30 points
ok 1 - three matches give 30 points

# tests 1
# suites 0
# pass 1
# fail 0
# cancelled 0
# skipped 0
# todo 0

Перші два рядки показують пакет і виконану команду, нижче йде назва тесту. Рядок ok 1 означає, що тест номер 1 пройшов; якщо тест упав, рядок починається з not ok. Рядки pass 1 і fail 0 кажуть: один тест пройшов, жоден не впав. Це й називають "зеленим" результатом, навіть якщо сам термінал не розфарбовує текст.

У варіанті з помилкою за три збіги виходить нагорода 3 очки, хоча за правилом належить 30. Той самий тест видає такий фрагмент; шлях, стек викликів, час і частину службових рядків тут пропущено:

not ok 1 - three matches give 30 points
  error: |-
    Expected values to be strictly equal:

    3 !== 30

  code: 'ERR_ASSERTION'
  name: 'AssertionError'
  expected: 30
  actual: 3
  operator: 'strictEqual'

# tests 1
# pass 0
# fail 1
# cancelled 0
# skipped 0
# todo 0

Спершу знайдіть ім'я тесту, потім порівняйте expected і actual. Перше означає "очікувалося", друге - "отримано". Тут очікувалося 30, отримано 3. Рядок fail 1 підбиває підсумок: один тест упав.

Таке падіння означає, що отримане не збіглося із записаним очікуванням. Далі потрібно з'ясувати причину: помилка в розрахунку, неправильні вихідні дані або хибне очікування в самому тесті. Змінювати число в перевірці лише заради успішного звіту не можна: спочатку звіряють правило завдання.

Буває й інше падіння: наприклад, тест не зміг підключити файл функції. Тоді до порівняння очок він взагалі не дійшов, а у звіті може не виявитися навіть назви потрібного тесту: упалим позначать увесь файл. Тому одного рядка fail 1 замало для висновку "розрахунок неправильний". Подивіться повідомлення над підсумком.

Пропущений тест

Тест має ще один важливий стан. Перевірку можуть позначити як пропущену; у Node.js це роблять, наприклад, через test.skip. Цей тест не виконується. Наявність його назви у звіті ще не означає, що сценарій перевірили.

В окремому запуску нашого прикладу пропущений тест дав такий рядок і підсумки:

ok 1 - three matches give 30 points # SKIP

# tests 1
# pass 0
# fail 0
# cancelled 0
# skipped 1
# todo 0

Зверніть увагу на незвичну деталь: рядок починається з ok, але закінчується # SKIP. Так цей формат позначає пропуск. Орієнтуватися лише на перше слово не можна; підсумок pass 0 підтверджує, що пройдених тестів тут немає.

Зведемо три запуски одного й того самого сценарію:

У великих звітах є інші рядки. У наших запусках cancelled і todo дорівнюють нулю. Якщо бачите ненульові значення, з'ясуйте, які тести скасовано або позначено як незавершені; не зараховуйте їх до успішно перевіреного. Рядок suites стосується груп тестів: у нашому прикладі груп немає.

І ще одна дрібниця, зовсім не дрібна. Якщо звіт показує нуль тестів, відсутність падінь не підтверджує нарахування. Потрібна перевірка могла не потрапити в запуск. Назва сценарію і кількість виконаних перевірок важливіші за загальне враження від кольору термінала.

Що означає зелений результат

Тест з показаного звіту відповів на вузьке запитання: "Чи правильно розраховано нагороду за три збіги?" Він не перевіряв нуль збігів, повторну заявку або число на сторінці. Ці випадки не стають перевіреними лише тому, що ми згадали їх у дорученні.

Щоб перевірити нуль збігів, потрібен ще один сценарій з окремим очікуванням 0. Щоб перевірити повторну заявку, доведеться описати саме повторну дію і її очікуваний результат. Тест не здогадається про ці правила із сусіднього коду. Перевіряється тільки те, що в ньому записано.

Відсутність тесту відрізняється від його пропуску. Пропущений тест видно у звіті як skipped. А про сценарій, для якого перевірку взагалі не написали, звіт зазвичай нічого не повідомляє. Усі наявні тести можуть пройти, хоча неперевірена поведінка містить помилку.

Нарешті, успішне порівняння не робить саме очікування правильним. Якщо для нашого правила помилково записати 3 замість 30 і розрахунок дасть 3, порівняння спокійно пройде. Тому, обговорюючи перевірку, корисно відповісти на два запитання: яку поведінку перевіряє тест і звідки взято очікуваний результат.

Фраза "тести пройшли" корисна, коли ви розумієте її межі. Вона повідомляє про успішне виконання конкретних перевірок у конкретному запуску. Обіцянки "у застосунку більше немає помилок" з неї не випливає.