В своей предыдущей статье я объяснил основы модульного тестирования и то, как Karma-Jasmine работает вместе для достижения этой цели. Я также объяснил некоторые базовые тесты в другой моей статье.
В этой статье мы остановимся на более интересном. Мы попробуем протестировать компонент, в который встроена служба. Вы можете получить исходный код для конкретного компонента из моего репозитория G itHub. Убрать из этой статьи следующие пункты:
- Тестирование компонента путем его изоляции от внешних зависимостей, таких как сервисы, и использования:
2. Знакомство со шпионами и то, как они могут оказаться полезным инструментом для модульного тестирования. Мы будем использовать следующих шпионов, подробности которых можно найти на странице Jasmine:
- шпион
- toHaveBeenCalled
- toHaveBeenCalledWith
- and.callThrough
- and.returnValue
Сценарий: мы будем создавать компонент с именем student.component.ts. Этот компонент будет обрабатывать следующие действия:
- Получите список студентов в сервисе.
- Показать данные студентов.
- Компонент показывает подробную информацию о пользователе, на которого щелкнули, путем вызова API.
Для начала мы создаем компонент, используя команду ниже, которая также создаст связанный с ним файл spec.
ng g c students
Я не буду вдаваться в код для разработки компонента функции и создания службы. Это очень просто, и его можно понять, взглянув на исходный код.
Будем тестировать:
- user_list заполнен некоторыми данными.
- Выбранная информация о пользователе отображается в HTML.
- Проверка правильной последовательности вызовов функций с помощью шпиона.
- Обработка ответа об ошибке от службы.
Как только ты побежишь
ng t
вы увидите сообщение об ошибке StaticInjectorError:
Чтобы исправить это, вам необходимо импортировать HttpClientModule в TestBed, поскольку мы используем вызовы http из наших служб, которые были введены в компонент.
«user_list» заполнен некоторыми данными
Давайте продолжим, проверим user_list и воспользуемся им для дальнейшего тестирования:
Вы увидите, что тестовый пример не работает, НО ПОЧЕМУ?
Это потому, что мы используем getUserList () для вызова Http и заполнения переменной с помощью нашего файла service, как показано ниже:
Основная суть модульного тестирования - изолировать компонент от других сервисов / зависимостей и создать собственные заглушки для имитации поведения сервиса.
Давайте создадим нашу собственную заглушку, чтобы повторить то, что student.service.ts раньше делал для student.component.ts используя useClass.
Проще говоря, useClass заменяет фактический экземпляр класса (StudentsService), введенный как свойство объекта «provide», на тот, который внедряется как свойство объекта «useClass» (StudentsServiceStub ).
{provide: StudentsService, useClass: StudentsServiceStub}
Бинго! Оно работает.
Выбранная информация о пользователе отображается в HTML
Мы можем получить доступ к HTML, используя:
fixture.debugElement.query(By.css('.users-div')).nativeElement
Мы также можем воспроизвести событие click и протестировать дальнейшее поведение HTML:
Обратите внимание, что нам пришлось вызвать fixture.detectChanges (), чтобы вручную запустить «Обнаружение изменений» и получить результаты на странице HTML.
Проверка правильной последовательности вызовов функций с помощью шпиона
Мы можем проверить, какие функции были вызваны и с какими параметрами они были вызваны, используя:
- .and.callThrough () [позволяет выполнять вызовы функций и шпионить за ними]
- toHaveBeenCalled () [проверяет, вызывалась ли отслеживаемая функция]
- toHaveBeenCalledWith () [проверяет, вызывалась ли отслеживаемая функция с ожидаемым параметром]
Обработка ответа об ошибке от службы
Мы можем переопределить поведение функции с помощью «spyOn» и вернуть настраиваемое значение с помощью. и.returnValue ().
throwError поступает из RxJS и предоставляет ответ об ошибке, который можно импортировать как
import { throwError } from 'rxjs';
Вот полные модульные тесты, которые мы написали в моем репозитории GitHub.
Ваше здоровье !!
