У цьому розділі ми розберемо основи автоматичного тестування. Воно буде застосовуватися далі в задачах, і взагалі, входить в «освітній мінімум» програміста.
При написанні функції ми зазвичай уявляємо, що вона повинна робити, яке значення на яких аргументах видавати.
У процесі розробки ми час від часу перевіряємо, чи правильно працює функція. Найпростіший спосіб перевірити - це запустити її, наприклад в консолі, і подивитися результат.
Якщо щось не так, поправити, знову запустити - подивитися результат ... І так «до переможного кінця».
Але такі ручні запуски - дуже недосконале засіб перевірки.
Коли перевіряєш роботу коду вручну - легко його «недотестіровать».
Наприклад, пишемо функцію f. Написали, тестуємо з різними аргументами. Виклик функції f (a) працює, а ось f (b) не працює. Поправили код - стало працювати f (b). зразок закінчили. Але при цьому забули заново протестувати f (a) - упс, от і можлива помилка в коді.
Автоматизоване тестування - це коли тести написані окремо від коду, і можна в будь-який момент запустити їх і перевірити всі важливі випадки використання.
Ми розглянемо методику тестування, яка входить в BDD - Behavior Driven Development. Підхід BDD давно і з успіхом використовується в багатьох проектах.
BDD - це не просто тести. Це набагато більше.
Тести BDD - це три в одному: І тести, І документація, І приклади використання.
Втім, вистачить слів. Розглянемо приклади.
Припустимо, ми хочемо розробити функцію pow (x, n). яка зводить x в цілу ступінь n. для простоти n≥0.
Ще до розробки ми можемо уявити собі, що ця функція буде робити, і описати це по методиці BDD.
Це опис називається специфікація (або, як кажуть в побуті, «спека») і виглядає так:
У специфікації є три основних будівельних блоку, які ви бачите в прикладі вище:
Задає, що саме ми описуємо, використовується для угруповання «робочих конячок» - блоків it. В даному випадку ми описуємо функцію pow.
У назві блоку it людською мовою описується, що повинна робити функція, далі йде тест. який перевіряє це.
Код всередині it. якщо реалізація вірна, повинен виконуватися без помилок.
Різні функції виду assert. * Використовуються, щоб перевірити, чи робить pow те, що задумано. Поки що нас цікавить тільки одна з них - assert.equal. вона порівнює свій перший аргумент з другим і видає помилку в разі, коли вони не рівні. В даному випадку вона перевіряє, що результат pow (2, 3) дорівнює 8.
Є й інші види порівнянь і перевірок, які ми побачимо далі.
Як правило, потік розробки такий:
- Пишеться специфікація, яка описує самий базовий функціонал.
- Робиться початкова реалізація.
- Для перевірки відповідності специфікації ми задіємо фреймворк (в нашому випадку Mocha). Фреймворк запускає всі тести it і виводить помилки, якщо вони виникнуть. При помилках вносяться виправлення.
- Специфікація розширюється, в неї додаються можливості, які поки, можливо, не підтримуються реалізацією.
- Йдемо на пункт 2, робимо реалізацію. І так «до переможного кінця».
Розробка ведеться итеративно. один прохід за іншим, поки специфікація і реалізація не будуть завершені.
У нашому випадку перший крок уже завершений, початкова специфікація готова, добре б приступити до реалізації. Але перед цим проведемо «нульовий» запуск специфікації, просто щоб побачити, що вже в такому вигляді, навіть без реалізації - тести працюють.
Ми будемо використовувати:
- Mocha - ця бібліотека містить загальні функції для тестування, включаючи describe і it.
- Chai - бібліотека підтримує різноманітні функції для перевірок. Є різні «стилі» перевірки результатів, з якими ми познайомимося пізніше, на поточний момент ми будемо використовувати лише assert.equal.
- Sinon - для емуляції і хитрою підміни функцій «заглушками», знадобиться пізніше.
Ці бібліотеки дозволяють тестувати JS не тільки в браузері, а й на сервері Node.JS. Тут ми розглянемо браузерні варіант, серверний використовує ті ж функції.
Приклад HTML-сторінки для тестів:
Цю сторінку можна умовно розділити на чотири частини:
- блок - в ньому ми підключаємо бібліотеки і стилі для тестування, нашого коду там немає.
- блок