Как сделать интеграционное тестирование для (Angularjs) веб-приложений

Я занимаюсь разработкой веб-приложения. Он состоит из 2 частей. Сервер остальных узлов и клиент angularjs.

Приложение структурировано следующим образом: Rest Server < -> Api Module < -> Angular App

Сервер в настоящее время хорошо протестирован. У меня есть модульные тесты и интеграционные тесты. Интеграционные тесты получают доступ к реальной базе данных и вызывают остальные API через http. Я думаю, что это настолько высокий уровень, насколько это возможно для тестирования сервера. Интеграционные тесты тоже работают быстро. Я вполне уверен, что способ тестирования сервера достаточен для моего варианта использования, и я доволен результатами.

Однако я изо всех сил пытаюсь протестировать приложение angularjs. У меня есть модульные тесты для соответствующих директив и модулей. Написание этих не было проблемой.

Я хотел бы написать интеграционные тесты, которые охватывают пользовательские сценарии. Что-то вроде сценария регистрации: пользователь посещает веб-сайт, переходит к форме регистрации и отправляет форму с данными.

Команда angularjs переходит от нг-сценариев к транспортиру . Транспортир использует Selenium для запуска тестов. Поэтому существует две области: область приложения и область тестирования.

Теперь я могу думать о трех разных абстракциях, которые я мог бы использовать. И я не уверен, какой из них подходит мне лучше всего.

• Макет модуля Api
• Макет сервера отдыха
• Использование полного сервера

Макет модуля Api

В В этом случае мне не нужно настраивать сервер. Все взаимодействия выполняются в браузере

Преимущество:

• Сервер не требуется

Недостаток:

• API находится в области видимости браузера, и я должен вмешаться в это.

Мне действительно нравится это решение, но мне трудно издеваться над API. Api необходимо изменить в области видимости браузера. Поэтому мне нужно отправить модификацию из теста в браузер. Это можно сделать , однако я не вижу, как я мог запустить утверждения типа mockedApi.method.wasCalledOnce() в области тестирования

Mock the Rest Server

Преимущество:

• Клиент будет неизменен
• Только одна область действия для решения

Недостаток:

• Необходимо настроить остальные маршруты

Я мог бы создать полный Mock Rest Server в nodejs. Тесты транспортира пишутся в nodejs, таким образом контроль сервера может быть сделан в тесте. Перед запуском теста я могу сказать серверу, как реагировать. Примерно так: server.onRequest({method: 'GET', url: '/'}).respondWith('hello world')

Тогда я могу сделать такие утверждения, как wasCalledOnce

Использовать полный сервер с базой данных

Каждый тест выполняется с полным сервером и может добавить элементы в базу данных. После каждого теста можно посмотреть ожидаемые элементы в базе данных

Преимущество:

• Можно быть уверенным, что если эти тесты запущены, приложение работает в тестируемом сценарии использования.

Недостаток:

• Я уже провел довольно интенсивный тест интеграции с остальным сервером. Это похоже на то же самое снова.
• Настройка зависит от полного сервера.

Текущее заключение

• Насмешка над Api полностью отделит сервер и клиента.
• Использование Mock Api было бы тестом более высокого уровня, но потребовало бы поддельного сервера
• Выполнение полного интеграционного теста дало бы наилучшую надежность, но это также сильно зависит от кода сервера

Что мне выбрать? Что бы вы сделали?