Вы получили это право. Есть (по крайней мере) три типа тестов:
- модульные тесты
- Интеграции тесты
- система тестирует
Вы можете найти хорошее объяснение here.
Каждый определяет те тесты, отличающиеся от. Моя перспектива:
- Unit тесты тестируют модуль/каждую функцию отдельно.
- Интеграции тесты тестирует весь рабочий процесс («Заполните регистрационную форму> отправка данных бакэнда> получение маркеров> входа»)
- тестирования системы - для меня - это: Прецеденты в Front End , Пример. Может ли пользователь войти в систему и представиться с профилем пользователя после ввода его учетных данных.
Что вы описываете - это единичный тест.Поэтому достаточно проверить, действительно ли ваша функция выполняет вызов API. Также проверьте, звоните ли вы по определенному URL-адресу и отправляете правильные данные.
Помните: вы часто проводите тесты с каждым изменением кода. Следовательно, было бы слишком много, чтобы всегда называть настоящий API.
From the Angular docs:
Во время модульного тестирования, мы хотим, чтобы наши модульные тесты, чтобы быстро бегать и не имеют никаких внешних зависимостей, так что мы не хотим, чтобы отправить XHR или JSONP просит к реальному серверу. Все, что нам действительно нужно, это проверить, был ли отправлен определенный запрос , или же просто разрешить приложению делать запросы, отвечать предварительно подготовленными ответами и утверждать, что конечный результат - это то, что мы ожидаем от него.
Вы можете проверить это с помощью $httpBackend.expect.
Итак, что, если конечная точка API меняет структуру данных?
- Получите, что вы тестируете бэкенд и получить, что вы посылаете данные, как определено
- Напишите интеграционный тест, где вы проверяете поток данных через определенный процесс (Логин, получающий данные для приборной панели и т.д.)
В конце концов, нет пуленепробиваемой концепции. Но эти шаги и менталитет уже являются хорошим доказательством для довольно крупного проекта.