Angular 2: как имитировать ChangeDetectorRef во время модульного тестирования

Обновление 2020:

Я написал это в мае 2017 года, это решение отлично работало в то время и работает до сих пор.

Мы не можем настроить внедрение макета changeDetectorRef через испытательный стенд, поэтому вот что я делаю в эти дни:

 it('detects changes', () => {
      // This is a unique instance here, brand new
      const changeDetectorRef = fixture.debugElement.injector.get(ChangeDetectorRef); 
     
      // So, I am spying directly on the prototype.
      const detectChangesSpy = spyOn(changeDetectorRef.constructor.prototype, 'detectChanges');

      component.someMethod(); // Which internally calls the detectChanges.

      expect(detectChangesSpy).toHaveBeenCalled();
    });

Тогда вам не нужны частные атрибуты или что-то еще.

В случае, если кто-то столкнется с этим, это один из способов, который хорошо сработал для меня:

Когда вы внедряете экземпляр ChangeDetectorRef в свой конструктор:

 constructor(private cdRef: ChangeDetectorRef) { }

У вас есть этот cdRef как один из частных атрибутов компонента, что означает, что вы можете шпионить за компонентом, заглушить этот атрибут и заставить его возвращать все, что вы хотите. Кроме того, вы можете утверждать его вызовы и параметры по мере необходимости.

В вашем файле спецификаций вызовите свой TestBed, не предоставляя ChangeDetectorRef, поскольку он не предоставит то, что вы ему даете. Установите тот же компонент перед каждым блоком, чтобы он сбрасывался между спецификациями, как это делается в документах здесь:

component = fixture.componentInstance;

Затем в тестах подсмотрите непосредственно атрибут

describe('someMethod()', () => {
  it('calls detect changes', () => {
    const spy = spyOn((component as any).cdRef, 'detectChanges');
    component.someMethod();

    expect(spy).toHaveBeenCalled();
  });
});

Со шпионом вы можете использовать .and.returnValue() и получить все, что вам нужно.

Обратите внимание, что (component as any) используется, поскольку cdRef является закрытым атрибутом. Но private не существует в самом скомпилированном javascript, поэтому он доступен.

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

Не уверен, что это новая вещь или нет, но к changeDetectorRef можно получить доступ через фикстуру.

См. документы: https://angular.io/guide/testing#componentfixture-properties

Мы столкнулись с той же проблемой с насмешкой детектора изменений, и это оказалось решением

Для модульного тестирования, если вы имитируете ChangeDetectorRef только для внедрения зависимостей для создаваемого компонента, вы можете передать любое значение.

Для моего случая я сделал так:

TestBed.configureTestingModule({
  providers: [
    FormBuilder,
    MyComponent,
    { provide: ChangeDetectorRef, useValue: {} }
  ]
}).compileComponents()
injector = getTestBed()
myComponent = injector.get(MyComponent)

Он успешно создаст myComponent. Просто убедитесь, что путь выполнения теста не нуждается в ChangeDetectorRef. Если вы это сделаете, замените useValue: {} подходящим фиктивным объектом.

В моем случае мне просто нужно было протестировать создание некоторых форм с помощью FormBuilder.

Вероятно, следует отметить один момент: по сути, здесь вы хотите протестировать свой собственный код, а не модульное тестирование самого детектора изменений (который был протестирован командой Angular). На мой взгляд, это хороший показатель того, что вы должны извлечь вызов детектора изменений в локальный частный метод (частный, поскольку это то, что вы не хотите тестировать), например.

private detectChanges(): void {
    this.cdRef.detectChanges();
}

Затем в своем модульном тесте вы захотите убедиться, что ваш код действительно вызвал эту функцию и, таким образом, вызвал метод из ChangeDetectorRef. Например:

it('should call the change detector',
    () => {
        const spyCDR = spyOn((cmp as any).cdRef, 'detectChanges' as any);
        cmp.ngOnInit();
        expect(spyCDR).toHaveBeenCalled();
    }
);

У меня была точно такая же ситуация, и это было предложено мне как общая передовая практика для модульного тестирования от старшего разработчика, который сказал мне, что модульное тестирование на самом деле вынуждает вас с помощью этого шаблона лучше структурировать ваш код. С предлагаемой реструктуризацией вы убедитесь, что ваш код гибок для изменения, например. если Angular изменит способ, которым они предоставляют нам обнаружение изменений, вам нужно будет только адаптировать метод detectChanges.