Test implementation guidelines for Ignite UI for Angular

Revision History

Version	User	Date	Notes
0.1	Zdravko Kolev	June 10, 2019	Initial version
0.2	Nikolay Alipiev	January 17, 2020	Angular component unit testing
0.3	Nikolay Alipiev / Plamena Miteva	March 30, 2020	Define new Guidelines

• Radoslav Karaivanov | Date:
• Konstantin Dinev | Date:

Prerequisites

• Angular Testing Guide
• Jasmine
• Run tests locally with ng test igniteui-angular

Examples

Here are some good examples of how to write new tests and how some of the old ones are refactored using the guide below.

New tests

Refactored tests

• igx-combo

Test implementation guidelines

Note: those guidelines should be applied only if reasonable

Globals

1. Define constants, when using a class name as a selector, at the top of the tests:

const CSS_CLASS_DRAG_ROW = 'igx-grid__tr--drag';

2. Define types for all variables and parameters:

let grid: IgxGridComponent;

3. The helper functions for the tests are in HelperUtils. Review and reuse them in tests instead of rewriting them.

4. For better performance, use NoopAnimationsModule to disable animatoions in tests where they are not the subject of tests:

import { NoopAnimationsModule } from '@angular/platform-browser/animations';

5. Implement different tests for each scenario, based on the Test plan.

Describes

1. Describes should be organized according to features/functionalities
2. Create one TestBed for each describe using beforeAll
3. In the TestBed declarations put only components which are used in the tests bellow and import necessary dependencies

describe('Initialization and rendering tests: ', () => {
    configureTestSuite();
    beforeAll(async(() => {
        TestBed.configureTestingModule({
            declarations: [
                IgxComboSampleComponent
            ],
            imports: [
                IgxComboModule,
                NoopAnimationsModule,
                IgxToggleModule
            ]
        }).compileComponents();
    }));
    ...

4. Call the configureTestSuite() method before the TestBed setup.

describe('Initialization and rendering tests: ', () => {
    configureTestSuite();

5. Use beforeEach in cases when all the tests use only one TestBed component rather than duplicate the TestBed configuration

beforeEach(async () => {
        fixture = TestBed.createComponent(IgxComboSampleComponent);
        component = fixture.componentInstance;
    });

6. Variables used in all/many tests is better to be defined in the scope of the describe and then reassigned in each test rather than repeat their declaration in each test:

describe('Custom ghost template tests', () => {
     let grid: IgxGridComponent;
     let rows: IgxGridRowComponent[];
     let dragRows: DebugElement[];
     configureTestSuite();
     beforeAll(async(() => {
     ...

Tests

1. Following Angular tutorials for component unit testing, what they suggest is to directly instantiate the component instead of creating a test fixture. Here is an example of such an approach:

select = new IgxSelectComponent(null, mockCdr, mockSelection, null, mockInjector);

Note: for such cases, you will need to mock the everything that you don't need including component features. If there are exceptions, in most cases, this will mean that a part of the component is not being mocked. Later move mock methods to util file. The testBed.get(), debugElement.injector() - instead of mocking, if mocking is complicated - get Directive input.injector.get(igxDateEditorDirective). Use methods, prop, (check row drag), mock methods, but use public properties from object prototype???

const mockInjector = jasmine.createSpyObj('Injector', {
	'get': mockNgControl
});

Note: In addition to all the unit tests, there is a single test that is responsible for testing if the bandings are properly called. Once this is tested, all other related tests can be unit tests using API.

Note: If there are several unit tests with direct component initialization, then you can specify separate describe for unit tests, but not necessary.

Example: select.component.spec.ts

2. Tests should be excluded with pending() function; Do not use x. Example:

it('my it block', () => {
   pending('my pending comment');
   ...
});

3. Don't use fix.WhenStable(), done(), setTimeout() when possible. if possible. Use (), then if needed fakeAsync() and at the end async(). Where there is async operations try using fakeAsync() with tick(), or if needed async() with await wait(). Sync tests should not have tick(), for async try the following order: tick() -> tick(DebounceTime ) -> await() -> await(DebounceTime) (TODO examples)
4. Where possible call components' API methods instead of making UI interaction.
5. For Virtualization use igxFor scroll methods (scrollTo()). You need async() for them.
6. Consider Jasmine async and callback when using promises - whenStable, rendering done, etc.
7. When using await wait use it with fixture.detectChanges(). When there are delays in the execution. For example, when testing Grid's scrolling or Resizing - this is because the scrolling is happening out of the zone.
8. Create helper functions - remove duplication and eventually move it to util.js (or use logic from there, especially keyboard triggers). There is already a lot of code in util.
9. Events - use triggerEventHandler() for the real interaction, instead of dispatchEvent(). In that case Angular lifecycle is skipped. Use util.
10. Focus events - use element.triggerEventhendle('focus') instead of element.nativeElement.focus().
11. Use Spies to:

• check for different calls. Example:

    it('should not trigger onRemove event when ..', () => {
        ...
        const firstChipComp = fix.componentInstance.chips.toArray()[0];
        spyOn(firstChipComp.onRemove, 'emit');

• prevent a certain function from execution. For example:

    // Spy the saveBlobToFile method so the files are not really created
    spyOn(ExportUtilities as any, 'saveBlobToFile');

13. When keyboard or mouse events are needed, the functions from the UIInteractions (ui-interactions.spec) should be used. For example UIInteractions.triggerKeyDownEvtUponElem('tab', cell.nativeElement, true),

Testbeds

1. Use separate describes. When multiple tests are using the same testBed, it should be initialized in a beforeEach. Example:

describe('IgxGrid - Multi Cell selection', () => {
    configureTestSuite();
    beforeEach(async(() => {
        TestBed.configureTestingModule({
            declarations: [
                SelectionWithScrollsComponent,
                SelectionWithTransactionsComponent
            ],
            imports: [NoopAnimationsModule, IgxGridModule]
        }).compileComponents();
    }));
    describe('Base', () => {
        ...
        beforeEach(fakeAsync(/** height/width setter rAF */() => {
           fixture = TestBed.createComponent(TestComponentX);
           ...
        }));

        it('Should be able to select a range with mouse dragging', () => {
...

2. When adding tests for the Grids (`igxGrid`, `igxTreeGrid`, `igxHieraticalGrid`) the testbeds from the files `grid-base-components.spec`, `grid-samples.spec` and `tree-grid-components.spec.ts` should be used or extended /Most probably one of the test components already defined in them would be suitable for your scenario/. When a new test component is necessary, add it to one of these files so it can be easily reused later. 

Refactor

In the end always do a self-review, to fix unclear test names, syntax errors, etc.

Future improvements

• Move e2e test outside unit test.
• Avoid defining test components in the test files. Define them in a separate file instead (for example, grid-samples.spec.ts) so they can be easily reused in other test files.