Common Keyboard Navigation Tests

The current package contains Jest tests based on the @progress/kendo-e2e package (Selenium). The package has been developed to guarantee the proper implementation of the Web Components and Tools Keyboard Navigation specification. The tests are shared for all products in the Progress WCT portfolio. They must be integrated and executed in the CI pipeline of the following products:

• Kendo UI for jQuery
• Kendo UI for Angular
• Kendo React
• Kendo UI for Vue
• Telerik UI for Blazor

Package Structure

The current package contains:

• src/components/ folder: Contains a separate file for each component that represents its tests definition. Some complex components (like the Grid), that would require different configuration scenarios have multiple test definition files. Each of those files contains tests for a separate scenario.
• src/components/[component-name].kb.tests.ts files: The component specific test definitions files. Each file contains a pre-condition test that validates the initial state of the tested page and the component configuration.
• src/components/[component-name].[scenario].kb.tests.ts files: Scenario specific test definitions files. Also contains a pre-condition validation test.
• src/index.ts file: Imports and lists all test definitions (components files) present in the package. Exports executeKbTests() method to be consumed by the WCT products for testing.
• src/data/ folder: Contains data to populate particular components that must be used in the test pages.
• pages/ folder: Contains scenario implementations using one of the Kendo favours. Needed so that the validation tests (present in the tests/ folder) could be run against a real scenario. Each test definition present in the components/ folder must have a scenario implementation in the pages/ folder.
• tests/ folder: Contains the validation test. All test definition files present in the components/ folder must be executed against a scenario implementation from the pages/ folder. The execution of this tests must be part of the package CI/CD.

Test Writing Guidelines

Note that as a prerequisite to write a test at least one of the WCT suites must properly implement all the keyboard shortcuts that are about to be tested. That is needed so that the test can be proofed-run (validated) on an implemented scenario.

Depending on the complexity of the component to be tested, there are 3 different approaches to write the tests:

• For the components with lowest complexity of keyboard navigation (for example, Button, ButtonGroup, AutoComplete) a single file with a single test definition must be present. That test should verify all the keyboard shortcuts available in the component.
• For components with more complex keyboard navigation, that can be fully tested in a single configuration scenario (for example, Calendar, MultiSelect) a single file with multiple test definitions must be present. Each of the tests should focus on a specific aspect of the keyboard navigation (for example navigation, single selection, multiple selection etc.).
• For components which require different configuration scenarios to test its keyboard navigation (for example Grid, Scheduler) a separate file with test definitions must be created for each scenario. Each of those files may contain a single of multiple tests.

In all cases, each file must contain a pre-condition test that validates the initial state of the tested page and the component configuration. Moreover, each file must contain a componentDescription constant describing in words the requirements for the test page, the component configuration, the data it is populated with and the initially selected (if any) value. That constant must be returned as a warning each time a check in the pre-condition validation fails.

Each new test definition file must be validated against a an implementation of a Kendo component. The implementation (scenario) must be added to the pages/ folder. The actual validation test must be added to the tests/validate.test.ts file.

Running Validation Tests

To run the validation tests:

• Run a server in the root of the package: npm run serve;
• Run Jest tests: npm run test;

Test Page Guidelines

Each test definition file would require a dedicated test page in each of the WCT suites. Each of those test pages must:

• Have only one component and that component must be the only focusable element on the page.
• The component configuration must follow the requirements set in the test definition pre-condition (see above).

Consuming Tests

The tests should be consumed across all Web Components and Tools products in the same way the validation tests are executed in the current package: \tests\validate.test.ts