Путаница между тестированием E2E, модульное тестирование и издевательские данные с помощью $httpBackend

Мы только начали разрабатывать веб-приложение с помощью AngularJS, и у нас возникли проблемы с его правильной проверкой, поэтому мы могли бы использовать некоторые советы.

Как правило, для тестирования требуются следующие компоненты:

Веб-интерфейс
Angular Контроллеры
Angular маршрутизация
HTML-рендеринг и Angular привязка контроллеров к элементам HTML

Как проверить все это с минимальными усилиями и, если возможно, перекрыться?

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

Учитывая вышеизложенное, я предполагаю, что лучше всего разорвать связь между сервером и клиентом и выполнить тесты Angular, используя только макетные данные.

Кроме того, я предполагаю, что если тестирование E2E позаботится обо всех возможных сценариях, контроллеры единичного тестирования являются избыточными, поскольку их значения привязаны к модели (и, таким образом, будут тестировать все вышеперечисленные 2, 3 и 4). Тестирование модулей было бы полезно только в очень сложных контроллерах или для тестирования служб и директив.

Однако мы не смогли найти какую-либо информацию о том, как издеваться над файлами $httpBackend на основе каждого теста, как и в модульных тестах, используя expect*(). Angular docs, похоже, предлагают использовать when*() плюс случайные passthrough(), когда это необходимо.

Но это создает вышеупомянутую проблему создания тестовых данных для всех сценариев, и вам, вероятно, потребуется reset БД в памяти перед каждым тестом, чтобы убедиться, что тесты не затронуты. Кроме того, вы теряете безопасность использования $httpBackEnd.expect*(), которая проверяет отсутствие отсутствующих или избыточных вызовов на сервер. Это говорит о том, что для проверки этого также потребуются контроллеры модулей тестирования.

Может ли кто-нибудь предоставить подробную стратегию тестирования для приложений AngularJS, которая предназначена для тестирования 4 компонентов выше, а также проблем, написанных выше?

Ответ 1

Не уверен - поскольку ваше приложение angular теоретически отделено от вашего бэкэнд, нет никакой особой причины, по которой тесты angular и базовые тесты должны быть объединены. Я бы тестировал их отдельно, причем каждый набор тестов предполагал, что другой компонент работает нормально. (Итак, при тестировании angular вы предполагаете, что сервер будет работать, как ожидалось.)
Единичные тесты - они обеспечивают большую глубину, чем тесты E2E. Легче проверить конкретные условия, с которыми столкнулся код. Кроме того, легко измазать все зависимости по мере необходимости и тестировать только компонент, который интересует модульные тесты. Модульные тесты не касаются того, как работает пользовательский интерфейс, или что правильные данные связаны правильно, а не бизнес-логики приложения является правильным.
(и 4) тесты E2E - меньшая степень детализации, с упором на то, чтобы пользовательский интерфейс выглядел как ожидаемый с точки зрения конечного пользователя. Вы правы, что это грязно, чтобы протестировать против живой базы данных (хотя некоторые люди пользуются безопасностью, обеспечиваемой полным сквозным интеграционным тестом), и поэтому вы должны использовать $httpBackend для издевки сервера.

Ответ 1

Ответ 2