Как обнаружить изменения API при издевательских тестах e2e?

Я хотел бы установить надежную основу тестирования e2e в нашем командном проекте, но я не могу найти простое решение этого вопроса:

Когда вы издеваетесь над всеми вашими вызовами, каков наилучший способ определить, была ли изменена реальная модель объектов, возвращаемых вашим сервером?

Ваши тесты все равно будут проходить, потому что они тестируют устаревшую версию модели, но приложение потенциально может быть повреждено.

Например, если макет предполагает, что /api/users/1 возвращает null, если пользователь не существует, когда он фактически возвращает пустой объект, то, хотя тесты могут пройти, проверяемое поведение основывается на неверных предположениях и поэтому может произойти непредвиденным образом.

Или, может быть, бэкэнд каким-то образом предоставляет статические json файлы с новейшей современной моделью, и frontend полагается на это?

Это, конечно, предполагает, что люди, работающие на бэкэнд и люди, работающие над интерфейсом, являются отдельными командами.

Я использую Angular 1.x и Protractor, но это не зависит от технологии.

Ответы

Ответ 1

Я думаю, что вы делаете (изоляция интерфейса во время тестов) правильно, держите его таким образом.

Что вы можете сделать, чтобы проверить свои mocks, является одним из следующих:

1) Если интерфейс и бэкэнд тесно связаны и разработаны вместе - добавьте набор модульных тестов для бэкэнд для проверки ответов API. Таким образом, если что-то изменится в API, тесты с базовым интерфейсом потерпят неудачу, и вы узнаете, что фреймворк должен быть обновлен.

Во время разработки вы можете запускать оба набора тестов (тесты e2e и backend) периодически или даже при каждом изменении кода.

2) Если интерфейс более или менее независим от бэкэнд, тогда вам нужно провести некоторые интеграционные тесты, которые вы будете запускать помимо тестов e2e. Они должны выполнять фактические HTTP-запросы на бэкэнд и сравнивать возвращаемую структуру данных с вашими mocks. Таким образом, вы можете обнаружить ситуацию, когда усталость устареет.

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

Ответ 2

Аналогичное решение для @Lablanc Meneses будет сохранять ответ каждого вызова в файле JSON. Сохраните ответ внутри intercepter для своих тестов e2e, а затем используйте сохраненный файл JSON для тестов e2e. Эти вызовы JSON будут автоматически обновляться при каждом запуске службы api. это потребует выполнения всех ваших услуг один раз, чтобы сохранить модель в первый раз, а затем использовать ее для ваших тестов e2e. Модель будет обновлена ​​сразу после запуска обновленного api. вы можете создать переключатель, чтобы остановить сохранение ответа для вашей сборки.

Ответ 3

Вам необходимо зарегистрировать http-перехватчик, в котором хранятся данные на request: window.e2eHttp[request.url] = null;, response + responseError: window.e2eHttp[request.url] = result;

Вы можете использовать модульную систему protractor angular для ввода или использования флага в вашем решении, e2eService.isEnabled(), для включения и выключения перехватчика.

Затем в вашем тестировании e2e вам нужно реализовать browser.wait + browser.executeScript, пока window.e2eHttp[request.url] не будет иметь данные. Он всегда будет иметь объект ответа angular http (заголовки состояния HTTP, данные и т.д.)