Угловой тестовый блок Карма / Жасмин: Объем теста

Question

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

Например, сценарий У меня есть обзорный компонент, который имеет 2 дочерних компонента, <app-refresh-button> и <canvas baseChart ...>, который использует обертку lib, ng2-charts (chartjs)).

<h1>Overview</h1>

<app-refresh-button 
  [isLoading]="isLoading"
  (onIntervalChange)="onSelectNewInterval($event)" 
  (onRefresh)="onRefreshManualClick($event)">
</app-refresh-button>

<canvas baseChart 
    [datasets]="lineChartData"
    ... ...
    (chartclick)="onChartClicked($event)"
</canvas>

После нажатия кнопки обновления точки данных будут вставлены в массив lineChartData и нанесены на график.

Теперь вот где я запутался:

• Поскольку <app-refresh-button> является дочерним компонентом, я не проверяю его в модульном тесте , это правильно?
• Если это так, логика в кнопке обновления ипостроение графика связано вместе, если я не проверю их вместе, как я узнаю, что они работают вместе ???
• Как насчет таких функций, как «pushingNewDataPoints ()», которые помещают новые данные вмассив lineChartData, который также находится в этом обзорном компоненте, проверять их?

Answer 1

Поскольку это дочерний компонент, я не проверяю его в модульный тест, это правильно?

Да, вы не должны тестировать его в модульных тестах.

Если это так, логика в кнопке обновления и построение графика связаны вместе, если я не проверю их вместе, как я знаю, что они работаем вместе ???

Я считаю, что есть два варианта:

1. Мелкие / Интеграционные тесты - в этих тестах вы предоставляете реальные компоненты и зависимости. Тогда вы можете проверить взаимодействие между ними так как есть реальная реализация позади. Вам следует отключить тяжелые сервисы / модули, такие как HttpClientModule, RouterModule или предоставить их тестовые эквиваленты.
2. Второй вариант - не предоставляйте реальные дочерние компоненты, вместо этого создавайте действительно простые макеты этих компонентов, которые позволяют вам проверять ваши дела (события, если данные установлены и т. Д.). После этого вы можете вызвать событие triggerEventHandler методом из DebugElement. Также есть возможность вообще не предоставлять детские компоненты (уход с этим) - https://angular.io/guide/testing#no_errors_schema затем вызвать события с помощью метода dispatchEvent из HTMLElement.

А как насчет таких функций, как "pushingNewDataPoints ()", которые новые данные в массив lineChartData, которые также находятся в этом компонент обзора, проверять их?

Похоже, что lineChartData общедоступно, поэтому вы можете вызвать событие на app-refresh-button, которое изменит lineChartData, а затем проверить, содержит ли оно правильные значения.

Answer 2

На этот вопрос сложно ответить, потому что он основан на мнениях.

Но лично я бы протестировал все привязки свойств и привязок событий на этих дочерних компонентах без проверки, что фактический дочерний компонент делает правильновещь с этими входами и выходами.

Полезной настройкой для этого является настройка NO_ERRORS_SCHEMA внутри вашей настройки TestBed.

Имея эту настройку, для привязки событий вы можете использовать triggerEventHandler.

const debugElem = fixture.debugElement.get(By.css('app-refresh-button'));
debugElem.triggerEventHandler('onIntervalChange', THE_EVENT_DATA_YOU_WANT_TO_USE_INSIDE_THE_TEST)

tick();

expect()...

Для привязок свойств вы также можете получить доступ к этим свойствам из debugElement:

const debugElem = fixture.debugElement.get(By.css('app-refresh-button'));
expect(debugElem.properties['isLoading']).toEqual(...)

Используя эти конструкции, вы можете проверить, что один выход с кнопки обновления изменяет ввод на холсте и т. Д.но вы не проверяете, что компоненты делают с этими входами и выходами.

Надеюсь, это поможет.