Ознайомлення з фронтенд-тестуванням. Частина перша. Вступ


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

Розповідає Гіл Тайяр, автор блогу на Hackernoon


Нещодавно моя подруга, яка розпочала вивчати чудовий світ фронтенд-розробки, запитала мене телефоном: “Як тестувати додаток?”. Я відповів, що не можу допомогти їй телефоном, оскільки мені потрібно багато часу для вивчення цієї теми, пообіцявши надіслати їй декілька посилань.

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

У результаті я вирішив написати його сам.

Що таке тестування?

На мій погляд, тестування – це код, який перевіряє, чи працює код твого додатка, так званий “промисловий код”, згідно з очікуваннями. Деякі люди мають на увазі TDD (розробку через тестування), специфічну методологію тестування, де тести пишуться на самому початку і спрямовують подальшу розробку продукту.

Прим. перекл. Про те, навіщо потрібна TDD, читайте в нашій статті.

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

На жаль, індустрія об’єднала ідею тестування і TDD, і через це у коду, написаного розробником паралельно з промисловим кодом, немає стандартного визначення. Я вирішив назвати його просто “тестуванням”.

Навіщо потрібне тестування?

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

Ні, я не збираюся обговорювати, навіщо треба тестування.

Типи тестування

Інша область, що збиває з пантелику людей, які почали вивчати тестування, – це різні типи тестів. Якщо Ви вивчали цю тему, то, напевно, чули про юніт-тестування, інтеграційне тестування, end- to-end (E2E) і компонентне тестування.

Ще гірше, що кожна людина описує ці поняття по-своєму.

Знову-таки, питання термінології мене мало обходять – я вважаю, що у типів тестування немає чіткого визначення. На мій погляд, усі тести лежать у діапазоні, який розпочинається з юніт-тестів і закінчується E2E- тестами.

Різноманіття типів тестування

Давайте розпочнемо з найпростішого – юніт-тесту. Юніт-тест – це за визначенням те, що тестує “юніт” (від англ. елемент). А що ж таке “юніт”? Це залежить від мови програмування. Юнітом може бути функція, модуль, пакет, клас, навіть об’єкт (у мовах типу JavaScript і Scala). У JavaScript юнит – це, звичайно, клас або модуль.

Прим. перекл. Радимо також прочитати наш переклад статті “Навіщо потрібні юніт-тести”.

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

Легко тестувати елемент коду окремо, коли він не залежить від інших елементів взагалі. Проте, якщо Вам необхідно протестувати юніт, який залежить від іншого елементу коду, то можете зробити дві речі: протестувати два юніти разом або замо́кати один з них.

За потреби протестувати два елементи коду разом, це може вважатися юніт-тестуванням? Педант скаже: “Ні”. На мою думку, це не має значення. Я зазвичай називаю такі тести юніт-тестами, але Ви можете називати їх інтеграційними тестами або подвійними юніт-тестами.

Що ж таке “мок”? Давайте подивимося на прикладі:

exports.writeSumToFile =  (a, b, fileSumWriter)  => { const sum = a + b
fileSumWriter (sum)}

Це модуль із функцією writeSumToFile, яка приймає два числа і записує їх суму у файл.

Зазначимо, що ми не пишемо у файл самі, це пише інша функція, fileSumWriter.

Для тестування цього модуля ми можемо реалізувати функцію запису у файл чесно, або зробити мок-реалізацію, яка не буде нічого і нікуди писати.

Коли ми передаємо мок у функцію, то тест стає юніт-тестом у значенні цього терміна. Але якби реалізація функції була чесною, багато людей не погодилися б з тим, що це юніт-тест.

Отже, з одного боку ми маємо юніт-тести, з іншого – E2E-тести і тести цілого додатка. Все тестується в E2E- тесті, а додаток працює так з тими ж налаштуваннями, що і в користувача.

Зі збільшенням кількості тестів об’єм протестованого коду збільшується, а замоканого коду – зменшується.

Інтеграційними тестами я називаю ті, які тестують більше, ніж юніт, але не тестують усі частини додатка. Отже, в який розділ Ви помістите свої тести? Багато людей стверджують, що є піраміда тестування: багато юніт-тестів, поменше інтеграційних і мала кількість E2E-тестів. Давайте поки що залишимо цю тему – я збираюся розібрати кожний з видів тестування окремо. Також я написав маленький додаток, який ми використовуватимемо з навчальною метою – його первинники можна знайти на GitHub.

Переклад статті “Testing Your Frontend Code: Part I (Introduction) “

Київ, Харків, Одеса, Дніпро, Запоріжжя, Кривий Ріг, Вінниця, Херсон, Черкаси, Житомир, Хмельницький, Чернівці, Рівне, Івано-Франківськ, Кременчук, Тернопіль, Луцьк, Ужгород, Кам'янець-Подільський, Стрий - за статистикою саме з цих міст програмісти найбільше переїжджають працювати до Львова. А Ви розглядаєте relocate?


Залишити відповідь

Ваша e-mail адреса не оприлюднюватиметься. Обов’язкові поля позначені *