Это руководство предлагает советы и методы для модульного и интеграционного тестирования приложений Angular.
Установка и конфигурации
Angular CLI загружает и устанавливает все необходимое для тестирования приложения Angular с помощью тестовой среды Jasmine.
Любой проект, созданный с помощью CLI, сразу же готов к тестированию. Просто запустите команду интерфейса командной строки ng test:
`` ng test``
T Команда ng test создает приложение в режиме просмотра и запускает средство выполнения теста Karma.
Вывод консоли выглядит примерно так:
`` `` 10% building modules 1/1 modules 0 активно ... ИНФОРМАЦИЯ [карма]: Сервер Karma v1.7.1 запущен по адресу http://0.0.0.0:9876/...INFO [launcher]: Запуск браузера Chrome ...... INFO [launcher]: Запуск браузера Chrome ... INFO [Chrome ...]: подключен к сокету ... Chrome ...: выполнено 3 из 3 УСПЕХ (0,135 сек/0,205 сек) ``
Последняя строка журнала самое главное. Он показывает, что Karma выполнила три теста, которые все прошли.
Также открывается браузер Chrome и отображает результаты теста в «Jasmine HTML Reporter», как показано в приведенном ниже фрагменте кода.
Конфигурация
CLI позаботится о конфигурации Jasmine и Karma за нас. Мы можем настроить многие параметры, отредактировав файлы karma.conf.js и test.ts в папке src/.
Файл karma.conf.js является частичным файлом конфигурации Karma. Интерфейс командной строки создает в памяти полную конфигурацию среды выполнения на основе структуры приложения, указанной в файле angular.json, дополненном karma.conf.js.
Вы также можете выполнить модульное тестирование приложения Angular с другим тестированием. библиотеки и тестовые программы. Каждая библиотека и средство выполнения имеют свои собственные процедуры установки, конфигурацию и синтаксис, которые не будут рассматриваться в этом руководстве.
Включить отчеты о покрытии кода
Интерфейс командной строки может запускать модульные тесты и создавать отчеты о покрытии кода. Отчеты о покрытии кода показывают вам любые части нашей базы кода, которые не могут быть должным образом протестированы вашими модульными тестами. Чтобы создать отчет о покрытии, выполните следующую команду в корне вашего проекта.
`ng test --no-watch --code-охват
По завершении тестов команда создает в проекте новую папку/охват. Откройте файл index.html, чтобы просмотреть отчет с исходным кодом и значениями покрытия кода.
Если вы хотите создавать отчеты о покрытии кода каждый раз при тестировании, вы можете установить следующий параметр в Файл конфигурации CLI, angular.json:
"test": {"options": {"codeCoverage": true}}
Живая демонстрация:
Это просто фрагмент кода, объясняющий конкретную концепцию и не имеющий вывода
См. Ручка mYXoyY от w3resource (@ w3resource) на CodePen.
Обеспечение покрытия кода
Процент покрытия кода позволяет вам оценить, какая часть вашего кода протестирована.
Если ваша команда решает установить минимальную сумму для модульного тестирования, вы можете обеспечить соблюдение этого минимума с помощью Angular CLI.
Например, предположим, что вам нужен код база должна иметь не менее 80% покрытия кода. Чтобы включить это, откройте файл конфигурации тестовой платформы Karma, karma.conf.js, и добавьте следующую строку в поле покрытияIstanbulReporter: key.
покрытияIstanbulReporter: {reports: ['html ',' lcovonly '], fixWebpackSourcePaths: true, пороги: {операторы: 80, строки: 80, ветки: 80, функции: 80}}
Live Демонстрация:
Это просто фрагмент кода, объясняющий конкретную концепцию, и может не иметь вывода
См. Pen yWvwYb от w3resource (@ w3resource) на CodePen.
Свойство thresholds заставляет инструмент применять минимум 80% покрытия кода при запуске модульных тестов в проекте.
Тесты служб
Службы часто являются самыми простыми файлами для модульного тестирования. Вот несколько синхронных и асинхронных модульных тестов ValueService, написанных без помощи утилит тестирования Angular.
//Прямое тестирование Jasmine без поддержки тестирования Angulardescribe ('ValueService', () = > {let service: ValueService; beforeEach (() => {service = new ValueService ();}); it ('# getValue должен возвращать реальное значение', () => {expect (service.getValue ()). toBe ('real value');}); it ('# getObservableValue должен возвращать значение из наблюдаемого', (done: DoneFn) => {service.getObservableValue (). subscribe (value => {expect (value) .toBe ('' наблюдаемое значение '); done ();});}); it (' # getPromiseValue должен возвращать значение из обещания ', (done: DoneFn) => {service.getPromiseValue (). then (value => {expect ( value) .toBe ('обещание значение'); done ();});});});
Живая демонстрация:
Это просто фрагмент кода, объясняющий конкретную концепцию, и может не иметь вывода
См. Pen zQRbKW от w3resource (@ w3resou rce) на CodePen.
Службы с зависимостями
Службы часто зависят от других служб, в которые Angular внедряет конструктор. Во многих случаях эти зависимости легко создать и внедрить вручную при вызове конструктора службы.
MasterService — это простой пример, показанный во фрагменте кода:
@Injectable () экспортный класс MasterService {конструктор (private valueService: ValueService) {} getValue () {return this.valueService.getValue (); }}
Живая демонстрация:
Это просто фрагмент кода, объясняющий конкретную концепцию, и может не иметь любой вывод
См. Pen byLZge от w3resource (@ w3resource) на CodePen.
Основы тестирования компонентов
Компонент, в отличие от всех других частей приложения Angular, объединяет HTML шаблон и класс TypeScript. Компонент действительно является шаблоном и классом, работающими вместе. и чтобы адекватно протестировать компонент, вы должны проверить, что они работают вместе, как задумано.
Такие тесты требуют создания хост-элемента компонента в DOM браузера, как это делает Angular, и исследования взаимодействия класса компонента с DOM, как описано в его шаблоне.
Angular TestBed облегчает этот вид тестирования, как вы увидите в разделах ниже. Но во многих случаях тестирование одного класса компонента без участия DOM может проверить большую часть поведения компонента более простым и очевидным способом.
Тестирование класса компонента
Тестируйте класс компонента отдельно, как если бы вы тестировали класс обслуживания. Рассмотрим этот LightswitchComponent во фрагменте кода ниже, который включает и выключает свет (представленный экранным сообщением), когда пользователь нажимает кнопку.
@Component ({selector) : 'lightswitch-comp', template: ` {{message}} `}) класс экспорта LightswitchComponent {isOn = ложный; clicked () {this.isOn =! this.isOn; } get message () {return `Свет $ {this.isOn? 'Вкл.': 'Выкл.'} `; }}
Живая демонстрация:
Это просто фрагмент кода, объясняющий конкретную концепцию, и может не иметь любой вывод
См. Pen ZNrPMo от w3resource (@ w3resource) на CodePen.
Вы можете решить только проверить, что метод clicked () переключает состояние включения/выключения света и соответствующим образом устанавливает сообщение.
Этот класс компонента не имеет зависимостей. Чтобы протестировать службу без зависимостей, вы создаете ее с помощью new, проверяете ее API и подтверждаете ожидания в отношении ее общедоступного состояния. Сделайте то же самое с классом компонента.
describe ('LightswitchComp', () => {it ('# clicked () должен переключать #isOn', () => {const comp = new LightswitchComponent (); expect (comp.isOn) .toBe (false, 'сначала выключить'); comp.clicked (); expect (comp.isOn) .toBe (true, 'после щелчка') ; comp.clicked (); expect (comp.isOn) .toBe (false, 'выключено после второго щелчка');}); it ('# clicked () должен установить #message на "включено"', () = > {const comp = new LightswitchComponent (); expect (comp.message) .toMatch (/is off/i, 'off at first'); comp.clicked (); expect (comp.message) .toMatch (/включен /i, 'on after clicked');});});
Живая демонстрация:
Это просто фрагмент кода, объясняющий конкретную концепцию, и может не иметь вывода
См. Pen mYXoQV от w3resource (@ w3resource) на CodePen.
Тестирование компонентной DOM
Тестировать класс компонента так же просто, как тестировать службу. Но компонент — это больше, чем просто его класс. Компонент взаимодействует с DOM и другими компонентами. Тесты только для класса могут рассказать вам о поведении класса. Они не могут сказать вам, будет ли компонент правильно отображаться, реагировать на ввод и жесты пользователя или интегрироваться с его родительскими и дочерними компонентами.
Ни один из приведенных выше тестов только для классов не может ответить на ключевые вопросы о том, как компоненты на самом деле ведут себя на экране.
- Привязан ли Lightswitch.clicked () к чему-либо, так что пользователь может его вызвать?
- сообщение Lightswitch. отображается?
- Может ли пользователь выбрать героя, отображаемого DashboardHeroComponent?
- Отображается ли имя героя должным образом (то есть в верхнем регистре)?
- Отображается ли приветственное сообщение шаблоном WelcomeComponent?
Эти вопросы могут не вызывать беспокойства для простых компонентов, проиллюстрированных выше. Но многие компоненты имеют сложное взаимодействие с элементами DOM, описанными в их шаблонах, в результате чего HTML появляется и исчезает при изменении состояния компонента.
Чтобы ответить на такие вопросы, вы должны создать элементы DOM. связанных с компонентами, вы должны изучить DOM, чтобы убедиться, что состояние компонента отображается правильно в нужное время, и вы должны имитировать взаимодействие пользователя с экраном, чтобы определить, заставляют ли эти взаимодействия компонент вести себя должным образом.
