Тестирование

Это руководство предлагает советы и методы для модульного и интеграционного тестирования приложений 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, чтобы убедиться, что состояние компонента отображается правильно в нужное время, и вы должны имитировать взаимодействие пользователя с экраном, чтобы определить, заставляют ли эти взаимодействия компонент вести себя должным образом.

Оцените статью
nanomode.ru
Добавить комментарий