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

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

Складіть перелік ризиків зі справжніх шляхів, архітектури, попередніх збоїв, регуляторних вимог, навантаження й частоти змін. Розподіліть між ними тести чистої логіки, відтворених компонентів, інтеграцій і договорів та невелику кількість наскрізних шляхів. Набір тестів має бути передбачуваним, придатним до діагностики й достатньо швидким, щоб запускатися в момент ухвалення рішення. Сучасні засоби Angular охоплюють Vitest, TestBed, виконання в браузері, засоби перевірки HTTP та випробувальні оболонки компонентів, але засоби лише підтримують стратегію, а не визначають її.

Починайте з ризику продукту й потрібних доказів

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

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

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

Модульними тестами перевіряйте рішення, а не внутрішнє налаштування платформи

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

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

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

Перевіряйте компоненти через їхній договір із користувачем

Компонент Angular складається з класу, шаблону, стилів, директив, упровадження залежностей і поведінки DOM. Відтворюйте його, якщо ризик стосується того, що людина бачить або робить. Шукайте елементи за роллю, підписом, текстом і сталим смисловим призначенням, а не за розташуванням CSS чи приватним станом компонента. Взаємодійте через DOM і перевіряйте видимий результат, надісланий предметний намір, навігацію, фокус, смисл вимкнення та доступне ім’я.

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

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

Перевіряйте договори API на межі

Типізовані виклики HttpClient не перевіряють JSON під час виконання. На межі перевіряйте метод, побудову URL, кодування параметрів, заголовки, облікові дані, тіло, скасування, граничний час, оброблення станів, правила повтору й перетворення транспортного DTO на предметну модель. Використовуйте випробувальну серверну частину HTTP Angular, щоб спостерігати запити й повертати успіх, неправильно сформовані дані, порожні тіла, структуровані помилки бізнесу, мережеві помилки й пізні відповіді без звернення до живого сервера.

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

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

Залишайте небагато наскрізних шляхів, але нехай вони дають вирішальні докази

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

Створюйте користувачів і дані через підтримувані API, але перевірювану поведінку виконуйте через інтерфейс. Перевіряйте стійкі результати в інтерфейсі та, за потреби, через серверну перевірку лише для читання. Віддавайте перевагу ролям, підписам та випробувальним ідентифікаторам, що подають сталі поняття продукту, а не ієрархії DOM чи створеним класам. Чекайте спостережуваного стану, відповіді, URL або умови елемента, а не заданого проміжку часу. За відмови зберігайте трасування, знімок екрана, повідомлення консолі, мережеві дані, серверний ідентифікатор зв’язку, випуск, браузер, розмір вікна й ідентифікатор даних.

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

Керуйте випробувальними даними, особами, часом і випадковістю

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

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

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

Ставтеся до нестабільних тестів як до вади робочої системи

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

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

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

Побудуйте CI як послідовність корисного зворотного зв’язку

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

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

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

• Розподіляйте докази за ризиком: зіставте критичні результати, види відмов, вплив, імовірність, можливість виявлення, стики архітектури, вади, що дійшли до користувачів, власників і найвужчу реалістичну межу тесту.
• Перевіряйте загальнодоступні рішення й поведінку: тримайте чисті правила поза компонентами, відтворюйте договори DOM, взаємодійте за змістом, перевіряйте доступність та уникайте тверджень, прив’язаних до внутрішньої будови.
• Захищайте межі служб: перевіряйте поведінку HTTP, перетворення під час виконання, схеми, зворотну сумісність, порядок перехоплювачів, особу, правила шлюзу, значення помилок і показові старі дані.
• Відбирайте наскрізні перевірки: охоплюйте вирішальні міжсистемні шляхи, створюйте ізольовані дані через API, чекайте спостережуваних умов, збирайте діагностичні матеріали й обирайте браузери за фактичними доказами.
• Керуйте непередбачуваністю: передавайте час і випадковість як залежності, ізолюйте клієнтів системи й особи, керуйте секретами, обмежуйте сторонні служби, усувайте залежність від порядку й робіть паралельне виконання безпечним.
• Керуйте системою зворотного зв’язку: призначайте власників нестабільних тестів і класифікуйте їх, обмежуйте ізоляцію, будуйте етапи CI за цінністю, перевіряйте кеш і вибір залежних тестів, публікуйте корисні докази, вимірюйте затримку й пропущені вади та вилучайте застарілі тести.