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
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.tsfiles: 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.tsfiles: Scenario specific test definitions files. Also contains a pre-condition validation test.
src/index.tsfile: 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
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
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).
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: