Підшкірний тест (Subcutaneous test)

Вперше згадка зустрічається у 2010 році у Jimmy Bougard у блозі : ”У той час як модульний тест фокусується на дрібномасштабному дизайні, підшкірний тест не стосується дизайну, а натомість перевіряє основні входи та виходи системи в цілому”, потім у доповіді Matt Davies and Rob Moore - " Microtesting - How We Set Fire To The Testing Pyramid While Ensuring Confidence ", а пізніше і в презентації Daniel Lafeir and Michael Lawrie. Термін «підшкірний» означає автоматизований тест безпосередньо під шаром інтерфейсу користувача. У MVC це будуть тести для всього, що знаходиться безпосередньо під контролером. Для веб-служби все, що знаходиться нижче за ендпоінта (endpoint).

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

• UI-тести повільні. Від цього нікуди не подітися. Їх можна запускати паралельно, допилювати напилком і робити трохи швидше, але вони залишаться повільними;

• UI-тести нестабільні. Частково тому, що вони повільні. А ще тому, що Web-браузер та інтерфейс користувача не були створені для того, щоб ними керував комп'ютер (нині цей тренд змінюється, але не факт, що це добре);

• UI-тести – це найбільш складні тести в написанні та підтримці. Вони просто тестують надто багато. (Це посилюється тим фактом, що часто люди беруть «ручні» тест-кейси і починають їх автоматизувати як є, без урахування різниці в ручному та автоматичному тестуванні);

• Нам кажуть, що нібито UI-тести емулюють реального користувача. Це не так. Користувач не шукатиме елемент на сторінці ID або XPath локатору. Користувач не заповнює форму зі швидкістю світла, і не «впаде», якщо якийсь елемент сторінки не буде доступний в якусь конкретну мілісекунду. І навіть тепер, коли браузери розробляються з урахуванням того, що браузером можна програмно керувати - це всього лише емуляція, навіть якщо дуже хороша;

• Хтось скаже, що деякий функціонал просто не можна протестувати інакше. Я скажу, що якщо є функціонал, який можна протестувати лише UI тестами (за винятком самої UI логіки) – це може бути гарною ознакою архітектурних проблем у продукті.

Таким чином визначення можна сформулювати так: “Якщо модульний тест тестує найменший компонент коду додатка, то підшкірний тест являє собою єдиний робочий процес (workflow), який можна ідентифікувати і протестувати в коді програми. Підшкірне тестування розглядає робочий процес як одиницю, що тестується”.

Варто пам'ятати, що це не пряма заміна автоматизації тестування через UI, а просто цілеспрямованіше тестування функціональності на потрібному рівні програми. Це дозволяє команді створювати більш досконалі наскрізні тести з використанням існуючого коду, фреймворку та/або бібліотек, доступних для зовнішньої програми. Основна мета цього виду тестування – зменшити нестабільність тесту та зосередитись на функціональності. Це дозволяє групі розрізняти функціональні збої через проблеми з кодом та збої додатків через проблеми сумісності або проблеми із зовнішніми залежностями. Оскільки підшкірні тести можна запускати з тим самим тестовим середовищем, що і модульні тести, вони не мають доступу до внутрішнього коду або викликів API під час роботи. Ізоляція цих тестів та використання імітуючих інструментів, які можуть імітувати виклики API та заглушки для різних взаємодій служб, можуть дати цілеспрямовану, ізольовану оцінку функціональності у зовнішньому стеку. Таке тестування функціональності дозволяє зробити будь-яку автоматизацію через браузер і інтерфейс користувача більш легкими. Це означає, що традиційні тести інтерфейсу користувача можуть бути дуже мінімальними і перевіряти тільки те, що зв'язки працюють між рівнями програми. Замість використання дорогих тестів графічного інтерфейсу та інтерфейсу користувача для отримання інформації про функціональність вони можуть бути поверхневими перевірками працездатності або димовими тестами. Уникаючи використання автоматизації інтерфейсу користувача, що стверджує очікування чогось функціонально працюючого, тести можуть стверджувати,

Оскільки під час підшкірного тестування використовуються всі компоненти на сторінці, створення інтегрованих тестів, які тестують лише кілька компонентів, або тестування одного компонента на рівні модуля може не знадобитися. Модульні тести можуть бути націлені на складнішу логіку, а не намагатися протестувати всю логіку навколо одного компонента, тестування базової логіки полегшує навантаження на модульне тестування. Підшкірне тестування використовує ту саму структуру тестування (наприклад, Jest), що модульні тести. Це зберігає функціональні тести внутрішніми і ближче до коду, що дає команді більше шансів на більш швидкий зворотний зв'язок і більш швидке налаштування тесту, ніж тестове середовище, яке підтримується окремо. Це означає, що командам не потрібно виконувати додаткову роботу з супроводу кількох фреймворків, репозиторіїв, а іноді і мов для виконання функціонального тестування інтерфейсу користувача. Тепер, коли підшкірне тестування дозволяє проводити функціональне тестування коду, а не через інтерфейс користувача, будь-які тести інтерфейсу користувача можуть бути скорочені до невеликої частини того, що було необхідно раніше. UI-тести можна використовувати як димові випробування. Таким чином вони можуть довести, що додаток та всі його рівні знаходяться у працездатному стані зв'язку. UI-тести можна використовувати як димові випробування. Таким чином вони можуть довести, що додаток та всі його рівні знаходяться у працездатному стані зв'язку. UI-тести можна використовувати як димові випробування. Таким чином вони можуть довести, що додаток та всі його рівні знаходяться у працездатному стані зв'язку.

Оскільки підшкірні тести орієнтовані поведінка високого рівня (high-level behavior), а чи не дизайн, вони ідеально підходять для стратегій тестування з урахуванням сценаріїв (scenario-based testing strategies), як-от BDD чи патерн Testcase Class per Fixture .

На жаль, поряд з усіма плюсами subcutaneous підходу ми можемо отримати і зниження покриття (coverage), зокрема glue code ( Сполучний код - програмний код, який служить виключно для «склеювання» різних частин коду, і при цьому не реалізує сам по собі жодну іншу прикладну функцію). Наскільки важлива втрата покриття в даному випадку? Залежить від ситуації. Ми втратили трохи glue code, який може бути (а може і не бути) важливим (рекомендую як вправу визначити, який код загубився). Чи виправдовує ця втрата покриття введення великовагового тестування на рівні UI? Це також залежить від ситуації. Ми можемо, наприклад:

• Додати один UI-тест для перевірки glue code, або

• Якщо ми не очікуємо частих змін glue code - залишити його без автотестів, або

• Якщо у нас є якийсь обсяг «ручного» тестування – є чудовий шанс, що проблеми з glue code будуть помічені тестувальником, або

• Придумати щось ще (той самий канарковий реліз, Canary deployment)

Один із способів уникнути втрати покриття - " Feature Tests Model "

Джерела:

• Introduction To Subcutaneous Testing
• Пишемо автотести ефективно – Subcutaneous tests + англ. версія + відеоверсія
• Subcutaneous Testing в ASP.NET Core