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

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

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

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

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

Ответ 2

Обратитесь к https://www.sitepoint.com/unit-and-e2e-testing-in-angularjs/. Если ваш сервис / factory использует службу http для вызова удаленного API, вы можете вернуть поддельные данные из него для модульного тестирования. Если вы начинаете новый проект Angular, подумайте об использовании тестов Protractor для E2E.