QA The Other WayОбеспечение качества в эпоху тестов, написанных искусственным интеллектом. QA The Other Way.
Практическое руководство по тестированию

Имитируйте зависимость. Обозначьте границу.

Высмеиваемая цитата может доказать, что ваш пользовательский интерфейс обрабатывает ответ. Он не может доказать, что служба котировок работает. Сохраняйте оба вида доказательств, не смешивая их названия.

7 мин. чтенияQA The Other Way
Миниатюрный мост рядом с настоящим стальным шарниром, иллюстрирующий высмеиваемую границу зависимости.
Редакционная иллюстрация, созданная искусственным интеллектом.
Иллюстративное видео к этой статье. английский экранный текст; выберите субтитры для этого языка.

Переведенное издание. Технические идентификаторы остаются в своей первоначальной форме.

Пользовательский интерфейс предложения по доставке, отображающий вымышленную стандартную цену 4,00.
Наглядная локальная демонстрация: пользовательский интерфейс отображает контролируемую котировку без обращения к поставщику.

Стоимость доставки не удалась во время проверки выпуска. Не работает пользовательский интерфейс кассы, недоступен поставщик котировок или тестовая среда потеряла свои учетные данные? Один красный результат теперь представляет несколько систем. Контролируемый ответ может помочь вам изучить пользовательский интерфейс, но он меняет значение результата.

В этом руководстве используется небольшой экран с ценами на доставку, чтобы показать, как смоделировать зависимость зависимостью и честно обозначить доказательства. Он основан на [руководстве по макетированию 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 выгодой является более четкий путь диагностики и продуманное покрытие отказных состояний. Для набора тестов, принадлежащего разработчику, все то же самое: сохраняйте повторяющиеся проверки пользовательского интерфейса, держите границу интеграции видимой и не позволяйте удобной моделируемой зависимости стать большим обещанием, чем может выдержать тест.

Общие вопросы

Высмеивайте зависимость. Обозначьте границу. - что мне следует иметь в виду?

Высмеиваемая цитата может доказать, что ваш пользовательский интерфейс обрабатывает ответ. Он не может доказать, что служба котировок работает. Сохраняйте оба вида доказательств, не смешивая их названия.

Являются ли примеры результатом измерения AnyTest?

Нет. Примеры иллюстрируют методы тестирования с использованием Playwright. AnyTest описывает исследование веб-страниц и создание сквозных тестов для проверки человеком; какая-либо конкретная интеграция бегуна не заявлена.

Источники