HeroService (hero.service.ts) интересен тем, что на первый взгляд его сложно протестировать, но это довольно просто, если знать, что тестировать. Взгляните на методgetHeroes:
Ой! Как же мы собираемся это проверить?
Как я всегда говорю, спрашивать, как тестировать код, обычно неправильно. Вместо этого вы хотите спросить: «Что, черт возьми, делает этот код?»
Так что же он делает?
- Он делает HTTP-вызов URL-адресу.
- Регистрирует результаты, добавляя сообщение с помощью службы сообщений.
- Если HTTP-вызов завершается неудачно, он регистрирует ошибку и выводит ее на консоль.
Вот самый важный абзац в этом посте:
У нас все должно быть хорошо, пока мы проверяем эти 3 вещи. Все остальное, что происходит с методами, — это просто шум. # 1 можно проверить двумя способами: заглушить службу HttpClient и ее методы или использовать Angular HttpClientTestingModule и HttpTestingController. В этом посте мы будем использовать последний. # 2 и # 3 просты, мы просто создаем заглушку для службы сообщений с массивом в ней, а затем добавляем в нее записи. Для проверки вывода на консоль (в #3) мы отслеживаем метод ошибки консоли.
Приступаем к тестированию
Первое, что нужно сделать, это сгенерировать тестовый каркас для hero.service.ts и посмотреть, что у нас получится:
получитьгероев
Мы уже упоминали getHeroes, поэтому начнем с него. Скаффолд вызывает метод getm по адресу api/heroes и что он возвращает пустой массив, но я думаю, что мы должны больше тестировать (насколько мы знаем, что вызов терпит неудачу и возвращает пустой массив). Давайте изменим его, чтобы мы тестировали непустой массив и добавили запись в службу сообщений.
Сначала мы модифицируем заглушку службы сообщений, чтобы мы могли отслеживать, что к ней добавлено:
А затем тест для getHeroes:
Обратите внимание, как мы получаем заглушки с помощью TestBed.get , сбрасываем массив с элементом hero и проверяем, что в ответе есть этот герой, и, наконец, проверяем, есть ли в службе сообщений запись с сообщением об успешном завершении («выбраны герои»).
Для неудачного пути (№ 3 в списке) мы просто сбрасываем ошибку вместо фактического значения, затем проверяем консольную ошибку и сообщение об ошибке в службе сообщений:
Теперь это было не так уж плохо. Остальные тесты будут упражнением по копированию/вставке с небольшими изменениями для каждого метода.
добавитьгероев
Это будет то же самое, что и getHeroes, но мы используем один герой вместо массива, метод http — POST, а результат ошибки — undefined вместо пустого массива:
обновлениеГерой
Вы знаете, к чему это приведет… так же, как addHero с PUT:
Если мы проверим покрытие, мы просто пропустим getHero, searchHero и deleteHero.
получитьгерой
Для getHero мы используем идентификатор героя в URL:
удалитьгерой
Этот немного отличается (хотя бы немного), потому что он может удалить героя по идентификатору или с фактическим объектом героя. Нам нужно протестировать оба сценария:
поискГерои
Это немного более интересно, потому что мы должны проверить, что служба НЕ делает http-вызов или регистрирует сообщение, если условие поиска пусто. Все остальное обычное до сих пор.
И это все. Теперь у нас есть заветное 100% покрытие:
Кстати, в копии Tour of Heroes, которую я получил, был метод под названием getHeroNo404, в котором не было ссылок, поэтому я просто удалил его. handleError также немного отличается от оригинала, я удалил значение параметра операции по умолчанию. Он не использовался.
Надеюсь, это поможет. Я знаю, что это было немного повторяющимся, но я хотел подчеркнуть тот факт, что на самом деле не так уж сложно тестировать http-сервисы, если вы знаете, как это сделать.
Использованная литература:
