Що таке flaky tests?
Флейки-тести, вони ж “флаки”, вони ж нестабільні, вони ж ненадійні, вони “моргають”, вони ж “випадково успішні”
Flaky-тест, буквально "бавовняний", "розсипається на шматочки", в індустрії ІТ-тестування означає нестабільний, ненадійний тест, який іноді "pass", іноді "fail", і важко зрозуміти, за якою закономірністю. Вбивця часу тестувальника, джерело нервозності у команді.
На такі випробування витрачається багато часу. Виникає затримка, поки команда не розбереться, у чому річ. Звичайно, страждає на продуктивність.
Причини коротко
Тестовий фреймворк спочатку погано зібраний. Його код не перевірено на відповідність завданням. Порада: код фреймворку повинен бути достатньо чистим; повинні дотримуватися принципів DRY, використовуватися Object design pattern сторінки, або Factory design pattern.
У тесті занадто багато hardcoded-даних. Нестабільність результатів тестів виникає коли ці тести запускаються в іншому оточенні. Треба відкоригувати hardcoded-дані (практика показує, що це найчастіше неправильно прописані шляхи до чогось, неправильні IP-адреси і т.п.).
Кешування попереднього стану тесту та запуск нового тесту з кешованими даними. Найкраще чистити кеш для кожного виконання тестів. Перевіряй дані перед кожним тестом, та очищай їхній стан після кожного тесту.
З зовнішньої причини, не пов'язаної із самими тестами. Погане підключення до Інтернету або конкретної бази даних; невідповідна версія браузера; витоку пам'яті.
"Втрата зв'язку" зі стороннім (3rd party) компонентом також призводить до ненадійності; тут допоможе ретельна перевірка сторонніх компонент перед запуском.
Неефективні селектори елементів (наприклад, XPATH), або некоректні координати елементів. Селектори можна поміняти досить легко, коригуючи дизайн сторінки. Рекомендується працювати з більш надійними селекторами (наприклад, "id" або "name").
Зловживання "sleep"-командами, що зупиняють виконання в очікуванні чогось. Тут допомагає заміна “sleep”-очікування більш надійне у плані “wait”-ожидания (поки елемент з'явиться). Це заощаджує час і (майже) усуває “моргання” тестів у багатьох випадках.
Що робити
Якщо є час, треба документувати такі тести і відправляти до “карантину”. Після виконання тестів, перевір виведені дані. Перевір логи, дампи пам'яті, стан системи. Можливо, скріншоти, якщо це UI-тести. У 90% випадків причина з'ясується вже на цьому етапі! Якщо ні, створи тикети щодо цих тестів, і перевір їх по одному в карантині, ретельно. Виключи тести в карантині з пайплайну до кінця перевірки, доки не досягнеш стабільності. У Google теж бувають flaky-тести, каже Hala Samir із Google; як вони вирішують цю проблему? Стандартно, наприклад, аналізують виведені дані, перевіряючи кореляцію з функціями, що можливо викликали нестабільність, по можливості без перезапуску тестів.
Ще раз про причини
Якщо поділити причини походження:
Тести власними силами мають “схильність до нестабільності”
Проблеми з фреймворком
Проблеми в бібліотеках/сервісах, що підключаються.
Проблеми в операційній системі / пристрої
Докладніше.
Як уже говорилося вище, нестабільність результатів часто виникає через неправильну ініціалізацію, або «очищення». Рідше, але теж відбувається - від неправильно підібраних тестових даних. Головний біль тестувальників – асинхронні дії, на це слід звертати особливу увагу. Простіша причина - неправильний порядок запуску тестів.
Проблеми з фреймворком: часто фреймворк не налаштований виділення достатніх системних ресурсів; або неправильно планує черговість запуску тестів, через що вони перекриваються між собою.
Якщо в проекті багато сторонніх бібліотек або сервісів, що підключаються, у них може бути своє "дерево залежностей", де і таяться причини нестабільності. Наприклад, змінні некоректно ініціалізуються; пам'ять "витікає"; якийсь ресурс не відповідає на запит; і т.п. Щоб виключити ці проблеми, в ідеалі треба прагнути “герметичності” тестового середовища, тобто тестове середовище не повинно мати зовнішніх залежностей.
Операційна система та тестові пристрої. Банально, але причиною іноді буває нестабільне підключення до Інтернету. Також банальна причина – помилки читання/запису на фізичний носій даних.
Статистика
Статистично (за словами тестувальників), основні причини нестабільності це: на першому місці за «складністю аналізу» асинхронні операції (async wait); потім багатопотокові операції; потім неправильний порядок запуску тестів; потім апаратні проблеми (з мережею та синхронізацією часу, або з пам'яттю).
Ну, а якщо знайти причину нестабільних тестів і виправити їх - не виходить ніяк, то, як говорив віце-президент Unity3D Алан Берд, "нестабільні тести ще гірші, ніж взагалі без тестів".
Джерела:
Дод. матеріал:
Last updated