Імітуйте залежність. Позначте межу.

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

У цьому посібнику використовується невеликий екран пропозиції доставки, щоб показати, як імітувати залежність залежність і чесно позначити докази. Він заснований на [посібнику з глузування Playwright] (залежність https://playwright.dev/docs/simulated) і мережевій документації. Екран, показаний тут, є локальною ілюстративною демонстрацією з вигаданими варіантами доставки, а не робочим процесом клієнта чи послугою в реальному часі.

Визначте, на яке питання відповідає тест

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

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

Встановіть маршрут до виконання запиту

У цій прикладній програмі завантаження сторінки цінової пропозиції вимагає /api/delivery-quote. Приклад перехоплює цей точний шлях і повертає контрольований об'єкт JSON. Зареєструйте обробник перед навігацією, щоб перший запит не міг уникнути запланованого налаштування.

await page.route('**/api/delivery-quote', async route => {
  await route.fulfill({
    status: 200,
    contentType: 'application/json',
    body: JSON.stringify({ label: 'Standard', price: '4.00' })
  });
});
await page.goto('/delivery-quote');
await expect(page.getByRole('status')).toHaveText('Standard: 4.00');

Використовуйте налаштовану проміжну базову URL-адресу для цієї відносної навігації. Форма відповіді – це наш демонстраційний контракт, а не універсальний API доставки. Справжній тест повинен використовувати вашу задокументовану схему та правила валюти. Збігайтеся лише з кінцевою точкою, якою ви збираєтеся керувати; перехоплення всього трафіку може приховати непов'язані збої.

Route API Playwright відрізняє виконання запиту від отримання справжньої відповіді та її модифікації. У наведеному вище прикладі не викликається служба котирування вгорі. Приклад route.fetch() матиме іншу межу, тому що вона все ще залежить від відповіді вище.

Перевірте стани помилок, не чекаючи збою постачальника

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

await page.route('**/api/delivery-quote', route =>
  route.fulfill({ status: 503, body: 'Unavailable' })
);
await page.goto('/delivery-quote');
await expect(page.getByRole('alert')).toHaveText('Quote unavailable');

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

Слідкуйте за сліпими зонами

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

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

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

Дайте доказу ім'я, яке залишиться на інформаційній панелі

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

AnyTest описує дослідження за допомогою URL-адрес і перевіряє рецензію людей. Застосуйте одне й те саме запитання щодо доказів до будь-якого запропонованого потоку: які залежності були реальними, які контрольованими та що встановлює пропуск? У цьому посібнику не стверджується, що всередині AnyTest є певний інтерфейс для знущань.

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