Метою тестування фронтенду є забезпечення того, щоб з кожним оновленням продукту користувачі були добре захищені від помилок. Відмова інвестувати ресурси в тестування помилок призведе до того, що користувачі перейдуть до пропозицій конкурентів. Але я впевнений, що ви цінуєте своїх користувачів і будете раді порадувати їх бездоганним продуктом. Тож сьогодні ми поговоримо про фреймворки тестування фронтенду та боротьбу з помилками на великих проектах.
Джерело: Деякі помилки, Amazon
Юніт-тестування фронтенду
Перший тип помилок — це помилки, які виникають під час розробки функцій. Вони виникають, коли розробник не зрозумів необхідні функції правильно або просто щось пропустив під час кодування.
Юніт-тести ідеально підходять для цього типу помилок, оскільки вони враховують можливі сценарії для одиниці та її поведінки. На фронтенді юніт-тестування може бути таким простим, як кнопка та спливаюче вікно: після натискання кнопки ми бачимо, як з'являється спливаюче вікно.
Розробник пише тест лише один раз, швидко запускає його під час розробки і бачить, як працює певна функція. Без цього автоматичного тесту фронтенд-розробник змушений вручну перезавантажувати сторінку, витрачати додатковий час на натискання елементів і перевірку статусу через консоль.
Існує також більш цікава категорія помилок — помилки, які виникають через відсутність тестів. Вони можуть виникати під час оновлень і коли вводяться нові функції. Ви можете натрапити на цей тип помилок, коли деякі старі функції не були враховані або поведінка деяких компонентів змінилася, і інші компоненти більше не можуть взаємодіяти з ними так, як раніше. Найгірше в помилках без тестів те, що розробники можуть писати нові функції і думати, що все в порядку, в той час як бомба величезної катастрофи, яка може призвести до шкоди вашій репутації та фінансових втрат, вже цокає.
Наприклад, Slack, широко використовуваний інструмент продуктивності для бізнесу, є частиною родини Salesforce і славиться своєю здатністю з'єднувати людей. Проте навіть таке потужне програмне забезпечення, як Slack, може стикатися з періодичними збої.
Нещодавно програмне забезпечення зазнало збою, який дозволив надсилати прямі повідомлення (DM) без згоди отримувача. Простими словами, це дозволяло будь-кому ініціювати DM без необхідності попереднього дозволу, що призвело до скарг користувачів через відсутність можливості вимкнути ці небажані повідомлення.
Це був перший випадок, коли Slack зіткнувся з такою критикою щодо свого розвитку та додатків до продукту. Проте на початку 2022 року Slack розпочав оновлення, які вплинули на досвід користувачів. Ці оновлення включали видалення можливості для користувачів включати термін "Slack" у своїх іменах користувачів. Крім того, сталася неприємна ситуація, коли Slack випадково видалив усі спільні канали разом з історіями чатів користувачів, що викликало невдоволення серед користувачів і зайняло місце в історії значних програмних збоїв.
Звичайно, фронтенд-розробник або QA могли б виявити ці помилки під час написання або перевірки коду, але якщо подумати, скільки часу потрібно на повторювану монотонну ітерацію, ви зрозумієте, що час, витрачений на написання тестів, які будуть повторно використовуватися в майбутньому, насправді був витрачений з користю.
Також іноді розробники занадто впевнені, що врахували все. Юніт-тест може також допомогти виявити помилки, які були пропущені через цей людський фактор. Розробники запускають їх, щоб перевірити свій власний код, і якщо вони виявляють деякі помилки, їх можна виправити відразу на місці.
Тести інтеграції
У відсутності тестів інтеграція певних компонентів також може призвести до помилок. Обидва компоненти можуть бути добре написані, але при використанні разом вони не працюють так, як очікувалося. Під час розробки деякі компоненти змінюються та вдосконалюються, тому спосіб їхньої роботи один з одним та з іншими компонентами також може змінитися.
Коли один компонент отримує від іншого те, чого не очікував, ми можемо легко отримати помилку і навіть не помітити цього. Щоб уникнути цієї ситуації, використовується тестування інтеграції. Воно перевіряє, чи стабільна взаємодія між окремими частинами.
e2e
Крім того, тестування end to end використовується для перевірки загальної роботи всієї системи та взаємодії між усіма її компонентами.
Прикладом фронтенду може бути форма для заповнення певних даних. Наші e2e тести завантажать сторінку, натиснуть різні кнопки, введуть дані та перевірять, чи все працює відповідно до вимог сценарію.
Давайте все покриємо e2e тестами!
Якщо ви не заглиблюєтеся, e2e тестування здається ідеальним. Ви можете використовувати його для перевірки всіх типів взаємодії між користувачем та інтерфейсом і виявляти ці помилки на ранніх етапах. Думка про те, що вам може знадобитися щось інше, навіть не спаде вам на думку, оскільки e2e тести допомагають виявити всі дефекти, які можуть помітити користувачі.
Але на практиці великі компанії, зокрема Google, стикаються з тим, що e2e тести не зовсім підходять для розробки, оскільки відстеження та виправлення помилок — це два окремі завдання. Для виправлення помилки критично важливо знати, яка частина коду за неї відповідає, але оскільки e2e тести є загальними, вони не можуть надати ці деталі. Ось чому в своїй статті Just Say No to More End-to-End Tests Google рекомендує дотримуватися наступного співвідношення для різних типів тестів:
70/20/10. 70% юніт-тестування фронтенду, 20% інтеграційних тестів і 10% e2e. Тут ми можемо зробити висновок, що чим легше знайти помилку, тим менше часу буде витрачено на її виправлення, а саме виправлення буде більш правильним. Наявність достатньої інформації про помилку прискорить випуск і допоможе зекономити кошти, витрачені на розробку програмного забезпечення.
Якщо ви візьмете невеликий проект, написаний одним розробником, спочатку можна обійтися без тестів. Ресурси обмежені, і чим швидше продукт буде випущений і перевірений в дії, тим краще. Але великі проекти з багатьма розробниками не зможуть довго виживати таким чином. Для них процес розробки без належного тестування фронтенду виглядатиме так:
Може здатися, що якщо зменшити час, витрачений на тести, ви випустите свій продукт раніше. Але насправді на виявлення помилок і виправлення тих, що не були усунуті на початку, буде витрачено набагато більше часу. Один розробник написав щось, інший спробував це покращити, і тепер це зламалося, але ви не дізнаєтеся про це, якщо не будуть проведені належні тести.
Великі проекти = великі тести
На мою скромну думку, якщо проект дуже маленький, іноді можливо (хоча і не рекомендується) обійтися без тестування. Але більші проекти, які продовжують розвиватися та покращуватися, просто не виживуть таким чином. Без тестування фронтенду терміни випуску не будуть дотримані, і з оновлення на оновлення проект стане все важче підтримувати та розвивати. Для бізнесу це призведе до непотрібних витрат і втрати найсприятливішого моменту для впровадження нових рішень для цільової аудиторії.
Потрібна розробка MVP, iOS та Android застосунків або прототипування? Перегляньте наше портфоліо та напишіть нам сьогодні!
