Автоматизація тест кейсів подібна на експедицію в джунглі технологій, де за кожним тест раном може чатувати ймовірність факапу.  У цьому матеріалі Марія Кочин, QA Automation Engineer у ІТ-компанії Boosta, поділилася топ 5 особистих bad practice, які часто призводять до проблем.

Марія Кочин, QA Automation Engineer у ІТ-компанії Boosta

1. Тести раняться цілу вічність, або не дочікуються певних елементів

Нам часто кажуть, що терпіння - це геройська якість, але коли мова йде про автоматизоване тестування, то не все так однозначно. Уявимо собі автотест як супергероя. Він весь такий сильний, швидкий, всемогутній, біжить, перевіряє все… і тут в нього стається browser.pause(). Це ніби визнати, що у нашого супергероя є слабкість і йому потрібно зупинятися, щоб відпочити. І хоча browser.pause()  створює невеликі перерви для наших тестів, варто використовувати його з обережністю. 

При використанні browser.pause() ми вручну визначаємо таймінг зупинки тесту. Це може призвести до ситуацій, коли ми чекаємо або зупиняємо тест надто довго, що призведе до збільшення часу виконання тестів або, навпаки, недостатньої зупинки для завантаження елементів.

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

У середовищах CI/CD, де тести автоматично виконуються без втручання користувача, browser.pause() може призвести до блокування тестового процесу та створення зайвих затримок.

А як же тоді дочікуватися на елементи чи певні події в тесті? WebDriverIO має багато інших методів для налаштування очікувань, таких як waitUntil, waitForExist, waitForDisplayed, waitForClickable тощо.

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

2. Зафейлені тести з помилками “promise”.

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

Бувало у вас, що раните тести, а функція повертає promise? Ось це і є проблема з асинхронністю. 

Точно так само, як ми обираємо слова у розмові, щоб уникнути непорозумінь, в світі автоматизованого тестування ключові слова також грають важливу роль.

Оскільки багато операцій у браузері є асинхронними, необхідно правильно використовувати ключові слова async та await. В іншому випадку, тести можуть видавати помилки або виконуватися неправильно. Є фреймворки для автоматизації, які самі справляються з асинхронністю (Cypress, наприклад), але при написанні тестів на WDIO потрібно знати ці деталі.

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

Часто буває, що автоматизатор намагається отримати значення асинхронного запиту до сервера без використання ключового слова await, що призводить до отримання undefined чи неправильних даних.

Як цього уникати?

1. Читайте документацію, вона завжди є нашим найкращим другом. 

2. Дивіться помилки у логах після тест рану: якщо функція повертає promise, варто подумати про використання await.

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

Коли наш test suite розростається, і кожен тест використовує ті самі дані, нам, мабуть, не хотілось би щоб наш код нагадував переповнений багажник, де ми шукаємо щось серед безладу. Один із шляхів уникнення цього хаосу – використання глобальних змінних, розміщених в окремому файлі. Це як мати власний "довідник" з даних для всіх наших тестів. 

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

Глобальні змінні дозволяють уникнути дублювання коду, оскільки тести можуть використовувати спільні дані з одного джерела.

Якщо потрібно змінити дані, що використовуються у кількох тестах, досить зробити це в одному місці.

4. Пастка запуску автотестів.

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

Безперечно, нод-модулі — це ще ті «лимони» в світі автоматизації. Проблеми і їх вирішення, пов’язані з цим, тягнуть на окрему статтю, а щоб не залишати цю тему відкритою, скажу, що більшість проблем вирішує видалення нод-модулів і встановлення їх назад (npm i). Коли вже зовсім біда і нічого не допомагає – просто перезавантажте свій ПК. 

5.  Element wasn’t found

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

У кого не бувало, що тести відпрацьовували прекрасно, а за деякий час все попадало? Розгляньмо деякі проблеми, які можуть виникнути в автоматизації через CSS селектори. 

1. Елементи мають динамічні атрибути, що дуже ускладнює їх пошук. У такому випадку можна використовувати частковий збіг, вибір за тегом чи вкладеністю, використовувати батьківські елементи або їх атрибути, які залишаються незмінними. Моє улюблене рішення в даній ситуації – попросити розробника додати нам розмітку (атрибути) для елементів, які ми використовуємо в автоматизації. З цим можуть виникнути складнощі, але це окрема тема.

2. Використання nth-child() може бути вкрай чутливим до будь-яких змін у структурі DOM. Якщо ми додаємо або видаляємо елементи, їх порядок може змінитися, що зробить селектор неактуальним. Щоб забезпечити стабільність селектора з nth-child(), нам може знадобитися велика кількість додаткових перевірок, які зроблять його менш читабельним і підвищать імовірність помилок. Використання nth-child() може бути корисним у деяких випадках, але важливо розуміти його обмеження та ризики при написанні автотестів. 

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

4. Один із поширених факапів, з яким можуть стикатися автоматизатори при написанні тестів, пов'язаний із селекторами, які жорстко прив'язані до макета сторінки. Хоча виглядає зручно, такий підхід має багато недоліків, серед яких:
   - при зміні макета селектор втрачає валідність;
   - неуніверсальність;
   - важкість рефакторингу.
   Тут пораджу розробити набір універсальних селекторів, які можна буде легко адаптувати до змін у макеті.  

5. Залежність від ієрархії може зробити селектори крихкими та непередбачуваними.

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

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

Як казав класик: "Факапи — це не кінець світу, це лише початок нового коду." Тож давайте будемо життєрадісними та гнучкими, як наші тести під час запуску на невідомому середовищі.