Тестирование компонент¶

Процесс тестирования Angular компонентов несколько отличается от тестирования сервисов и других сущностей, поскольку компонент - это результат взаимодействия класса и HTML-шаблона, что необходимо учитывать при тестировании.

Тест, проверяющий представление и класс, требует создания компонента в браузере, как в реально работающем приложении, что требует немного больших ресурсов.

Если вам необходимо убедиться в правильности описания логики класса, никак не влияющей на отображение, то отпадает необходимость определять компонент в структуре DOM.

Рассмотрим пример.

login-form.component.ts

@Component({
  selector: 'login-form',
  template: `
    <form>
      <input
        type="text"
        name="name"
        [value]="loginForm.name"
      />
      <input
        type="password"
        name="password"
        [value]="loginForm.password"
      />
    </form>

    <button (click)="send()" [disabled]="!active">
      Send
    </button>
  `,
})
export class LoginFormComponent implements OnInit {
  @Input() active: boolean
  @Output() validate: EventEmitter<any> = new EventEmitter<
    any
  >()

  loginForm: any = {
    name: '',
    password: '',
  }

  constructor() {}

  ngOnInit() {
    this.loginForm.name = 'Bob'
    this.loginForm.password = 'qwerty'
  }

  send() {
    this.validate.emit(this.loginForm)
  }
}

login-form.component.spec.ts

describe('LoginForm component', () => {
  let comp

  beforeEach(() => {
    comp = new LoginFormComponent()
  })

  it('should set LoginForm values in OnInit', () => {
    comp.ngOnInit()
    expect(comp.loginForm.name).toBe('Bob', 'name value')
    expect(comp.loginForm.password).toBe(
      'qwerty',
      'password value'
    )
  })

  it('send() should raise LoginForm values', () => {
    comp.ngOnInit()
    comp.active = true

    comp.validate.subscribe((credentials) => {
      expect(comp.active).toBe(true, 'active')
      expect(credentials).toBe(comp.loginForm, 'send event')
    })

    comp.send()
  })
})

Если у компонента нет зависимостей, то экземпляр его класса в тесте создается с помощью ключевого слова new и без использования утилиты TestBed.

Первый тест проверяет установку значений формы в момент инициализации компонента, второй - возникновение события validate, инициируемое методом send().

Обратите внимание на то, как осуществляется проверка @Input() и @Output() свойств.

В процессе Angular component testing методы жизненного цикла не вызываются по умолчанию, как в реально работающем приложении. В тестах их вызов осуществляется явно.

Приступим к тестированию компонентов Angular с проверкой шаблона.

info-message.component.ts

@Component({
  selector: 'info-message',
  template: `
    <h1>Message title</h1>

    <p>Message content</p>
  `,
})
export class InfoMessageComponent {
  constructor() {}
}

info-message.component.spec.ts

describe('InfoMessage component', () => {
  let fixture: ComponentFixture<InfoMessageComponent>

  beforeEach(() => {
    TestBed.configureTestingModule({
      declarations: [InfoMessageComponent],
    })

    fixture = TestBed.createComponent(InfoMessageComponent)
  })

  it('should create', () => {
    const comp = fixture.componentInstance
    expect(comp).toBeDefined()
  })

  it('should contain "title"', () => {
    const infoMessageEl: HTMLElement = fixture.nativeElement
    const h1 = infoMessageEl.querySelector('h1')
    expect(h1.textContent).toContain('title')
  })
})

Метод createComponent() создает указанный компонент в DOM-дереве тестовой среды и возвращает объект типа ComponentFixture, через который можно получить доступ к экземпляру компонента используя свойство componentInstance и убедиться в том, что компонент инициализирован в DOM.

expect(comp).toBeDefined()

Другое полезное свойство объекта ComponentFixture - nativeElement. Значение свойства - объект типа HTMLElement. У объектов HTMLElement имеется метод querySelector, который по заданному селектору осуществляет поиск элементов в пределах шаблона компонента и также возвращает объект или массив объектов типа HTMLElement.

const h1 = infoMessageEl.querySelector('h1')

Свойства объекта nativeElement напрямую зависят от среды выполнения теста. Например, вне браузера DOM-эмуляция просто невозможна, например, в приложении Angular Universal, именно поэтому имеется свойство debugElement с объектом типа DebugElement в качестве значения. В объекте также имеется объект nativeElement, который работает универсально независимо от платформы. Поэтому рекомендуется при написании тестов придерживаться следующего формата:

const infoMessageEl: HTMLElement =
  fixture.debugElement.nativeElement

Правда, если платформа не браузерная, то метод querySelector() не сработает. Аналогом являются query() и queryAll() объекта debugElement, принимающего результат, возвращаемый статическим методом css() класса By. Класс By входит в состав библиотеки @angular/platform-browser.

it('should contain "title"', () => {
  const infoMessageEl: HTMLElement =
    fixture.debugElement.nativeElement
  const h1 = infoMessageEl.query(By.css('h1'))
  expect(h1.textContent).toContain('title')
})

By.css() принимает селектор в формате, аналогичному в querySelector().

В последних примерах проверялось статическое содержимое элементов HTML-разметки, т. е. текст присутствовал в шаблоне еще до компиляции компонента. Но при задании значения вот так

@Component({
  selector: 'info-message',
  template: `
    <h1>{{ title }}</h1>

    <p>Message content</p>
  `,
})
export class InfoMessageComponent {
  title = 'Attention'

  constructor() {}
}

тесты выполнились бы, поскольку createComponent() не связывает класс компонента с его шаблоном. Все переменные в таком случаем заменяются на пустые строки. Для инициации привязки необходимо вызвать detectChanges() у объекта, возвращаемого после вызова метода createComponent().

it('should contain "title"', () => {
  fixture.detectChanges()
  const infoMessageEl: HTMLElement =
    fixture.debugElement.nativeElement
  const h1 = infoMessageEl.querySelector('h1')
  expect(h1.textContent).toContain('Attention')
})

Еще одна особенность приведенных ранее примеров - определение верстки в одном файле с определением класса. Но чаще всего (и это правильно) HTML-код и стили к нему выносятся в отдельные файлы. В таком случае необходимо вслед за методом configureTestingModule() вызвать compileComponents().

Принудительная компиляция необходима только если тестирование Angular компонентов выполняется вне среды CLI. В случае запуска через Angular CLI компиляция происходит автоматически.

beforeEach(async(() => {
  TestBed.configureTestingModule({
    declarations: [InfoMessageComponent],
  })
    .compileComponents()
    .then(() => {
      fixture = TestBed.createComponent(
        InfoMessageComponent
      )
    })
}))

Асинхронный compileComponents() возвращает Promise и вызывается совместно с асинхронной функцией async() из библиотеки @angular/core/testing. Все синхронные операции после компиляции компонентов должны указываться в части then(), иначе будет сгенерировано исключение.

Вызов метода абсолютно безвреден. Обращение к compileComponents() без необходимости никак не повлияет на время и производительность тестирования.

Ссылки¶

Component Test Basics

Тестирование компонент¶

Ссылки¶

Комментарии