Некоторое время я был разочарован тем, сколько, кажется, нужно издеваться, чтобы организовать простые модульные тесты для сервисов, перехватчиков и т. д. Мне удалось то, что я считаю хорошим и чистым способом модульного тестирования перехватчика, который изменяет ваш URL .
Перехватчик
Это не точная копия моего рабочего кода, но она иллюстрирует предполагаемую логику: если мы вызываем конечную точку, которая начинается с одного префикса, мы указываем этот запрос на один целевой сервер, на котором не находится пользовательский интерфейс, если это второй (или третий и т. д.), мы нацеливаемся на второй.
Теперь о той части, которая вызвала у меня чрезмерный стресс: выяснить, как провести модульное тестирование этой части функциональности, чтобы убедиться, что мы действительно добавляем наш целевой сервер к нашим запросам.
Устроить тесты
Здесь вы можете видеть, что мы издеваемся над обработчиком, как это принято в то время. Но как только мы вызываем метод перехвата, мы передаем ему новый HttpRequest и ожидаем, что шпион будет содержать объект, но поскольку объект, который мы возвращаем, очень большой, мы хотим только проверить, был ли изменен URL-адрес.
Мы можем проверить шпиона с помощью «toBeCalledWith», а затем сузить этот огромный объект (проверить его в журнале консоли) с помощью «objectContaining», а затем получить доступ к этому свойству { url: yourModifiedUrl }. Также обязательно вызовите done().
Краткое содержание
Я уверен, что люди, которые пишут такие тесты чаще, чем я, уже знают об этом, и кажется интуитивно понятным, потому что, оглядываясь назад, я думаю, как я не подумал об этом первым, но я рад, что «нашел это решение. Если у кого-то есть небольшие фрагменты или полезные советы, с которыми они столкнулись при попытке упростить модульные тесты, особенно с Angular, поделитесь ими ниже или дайте ссылку на свой собственный учебник.
Я думаю, что начинаю видеть тему для своих сообщений в блоге. Можно переименовать их в «Разочарованный разработчик».
