Коли ми пишемо код, як ми можемо дізнатися, що він правильний? Добре, давайте здогадаюся, ви спочатку пишете код, а потім тестуєте його, так? Окей, такий підхід має сенс, коли код невеликий або короткий. Але що, якщо код, який ви пишете, стане величезним і буде складатися з тисяч рядків? А також, що якщо до команди приєднається новий розробник?
А що, якщо ми змінюємо код в певній частині? Як ми можемо бути впевненими, що зміни не порушать роботу інших частин коду, який ми вже написали? Чи будете ви перевіряти кожен ваш рядок коду вручну після написання? Не буде це дуже клопітно і забере багато часу? Якщо так, робота розробника здається справжнім випробуванням.
Можливо, хтось із вас може подумати чи заперечити так:
"Що ж особливого в тестуванні коду, який ми пишемо? Хіба не достатньо просто перевірити програму після її завершення, щоб побачити, чи працює сайт без помилок і чи відповідає він нашим вимогам?"
Але зачекайте, те, про що ми зараз говоримо — це тестування, яке надзвичайно ефективне і швидке. Дозвольте представити Автоматизоване тестування (Automation Testing).
Чи замислювались ви колись, що можна автоматично тестувати код? Якщо ви ще не пробували цього або тільки починаєте вивчати програмування і раніше не чули про це, то зараз саме час ознайомитись з цією статтею.
Що таке Automation Test?
Автоматизоване тестування — це тестування, яке виконується комп’ютером без участі реального користувача. Ми можемо налаштувати його для виконання тестів в потрібній кількості, без сорому, як коли ми питаємо наївне питання, а краще запитати, ніж не знати відповіді.
Тепер давайте подивимося на код, подивіться на наступний приклад:
function concatStrings(strA, strB) {
return strA + strB;
}
concatStrings('Hello', 'World');
Звісно, ви можете побачити, що результатом виконання цього коду буде “HelloWorld”. Тут викликається функція "concatStrings", що означає об'єднання двох рядків в один. Це досить легко перевірити, чи не так? Адже тут дуже мало коду, що потрібно перевірити.
А як бути, якщо потрібно протестувати величезний код? Що якщо вам буде важко навіть прочитати і зрозуміти його? Це може бути важко. Але ми повинні працювати не важче, а розумніше. Ось чому нам потрібне автоматизоване тестування.
Подивіться на наступний код:
expect(concatStrings('Hello', 'World')).toBe('HelloWorld');
Ми даємо команду JavaScript перевірити, чи відповідає очікуваний результат (Expect) фактичному результату (ToBe). Якщо так, то нам буде показано відповідний звіт.
А що якщо результат не відповідає очікуванням? Звісно, є спосіб виправити помилки в коді.
expect(concatStrings(1, 2)).toBe('12');
Ось приклад звіту, який можна отримати.
Тест пройшов успішно (ЗЕЛЕНИЙ):
PASS tests/concatStrings.test.js
Join Strings
✓ should concatenate two strings properly (1 ms)
Test Suites: 1 passed, 1 total
Tests: 1 passed, 1 total
Snapshots: 0 total
Time: 0.641 s, estimated 1 s
Ran all test suites.
Тест не пройшов (ЧЕРВОНИЙ):
FAIL tests/concatStrings.test.js
Join Strings
✓ should concatenate string Hello and World properly (2 ms)
✕ should concatenate string 1 and 2 properly (1 ms)
● Join Strings › should concatenate string 1 and 2 properly
expect(received).toBe(expected) // Object.is equality
Expected: "12"
Received: 3
9 |
10 | it('should concatenate string 1 and 2 properly', () => {
> 11 | expect(concatStrings(1, 2)).toBe('12');
| ^
12 | });
13 | });
14 |
at Object.toBe (tests/concatStrings.test.js:11:33)
Test Suites: 1 failed, 1 total
Tests: 1 failed, 1 passed, 2 total
Snapshots: 0 total
Time: 0.908 s, estimated 1 s
Ran all test suites.
Мабуть, ви запитаєте, чому цей код не пройшов тест? Це сталося тому, що наша очікувана поведінка була такою, що два параметри повинні були бути об'єднані. Але насправді відбулася математична операція додавання. Це один із прикладів, який показує, наскільки важливим є тестування.
Що це означає? Функцію concatStrings потрібно виправити, щоб вона коректно обробляла цей випадок.
TTD (Test-Driven Development), Техніка Тестування
Не є чимось незвичним тестувати програму після того, як вона готова. Ми вже бачили такий приклад раніше. У нас є функція, і ми її тестуємо. Однак, чи чули ви про техніку написання тестів до того, як розпочати розробку функцій? Це звучить цікаво, чи не так?
Розробка функцій з TTD (Test-Driven Development) передбачає, що ми спочатку пишемо тестові кодові приклади, а потім розробляємо сам код програми. Якщо ви думаєте, що це неможливо або дуже складно — ви не помиляєтесь, адже ще не написано сам код. Тому на початку тест може не пройти.
Але тепер наша задача — зробити його зеленим, тобто успішним. Для цього ми повинні написати програмний код так, щоб тестові очікування виконувалися. Потім ми оптимізуємо код, щоб зробити його більш ефективним, і одночасно оптимізуємо самі тести, зменшуючи дублювання коду.
Після того, як тест пройде успішно, ми повертаємося до написання наступного тесту, з іншими випадками, покриваючи всі можливі сценарії функціоналу, який ми будуємо.
Щоб краще зрозуміти цей процес, дивіться на схему нижче.
Ця схема ілюструє цикл, який називається red-green-refactor cycle. Це основа для TTD. Взагалі, TTD складається з трьох основних етапів.
1. Напишіть тест
Напишіть тестовий код перед тим, як писати програмний код. Переконайтеся, що тест не проходить. Якщо він проходить, перевірте тест, ймовірно, ви помилились, адже тест повинен не пройти, якщо ви ще не написали відповідного коду.
2. Зробіть, щоб тест пройшов
Коли тест показує червону помилку, потрібно зробити його зеленим. Для цього пишемо мінімальний код, щоб тест пройшов.
3. Зробіть це правильно
Після того, як ви переконаєтесь, що код працює правильно, настав час оптимізувати його. Один з трюків, які ми можемо застосувати, — це зменшення дублювання коду.
Перекладено з: Berkenalan dengan Pengujian Otomatis