Documentation

You are viewing documentation for Vaadin 23. View latest documentation

Documentation

Testing of Java Integration for Web Components

Contributions, which include enhancements or new features, should include tests that verify the enhancement or new feature works as expected. The same advice and rules apply as when creating tests for web components.

Best practices include:

Module Structure

Components wrappers implementations for Flow have modular structure. When coming up with a test for the contribution start with the main component module (for example, vaadin-button-flow). Unit tests are located there under src/test/.... Integration tests are located in the integration-tests module (for example, vaadin-button-flow-integration-tests)

Unit Tests

If the whole fix or feature, or part of its logic can be tested without roundtrip to the client-side, new unit test should be created. Files names are separated by the topic categories they are covering. Creation of the new file is acceptable following the same advices as for web-components tests.

The technologies / libraries used for the test creation can be found from imports. For example, in existing unit tests of vaadin-button-flow @Test annotation is used which lead to org.junit.Test import.

Good practice would be to follow the existing test structure and naming conventions. For example, action and result mentioned in removeNullColumn_throws.

Integrations Tests

If contribution’s logic need to be tested with roundtrip to the client-side or in conjunction with other components, new integration test need to be added. Start with reviewing the existing structure of the integration-tests module of the component to which contribution is done. They have similar structure, but more complex component requires more complex tests.

For example, vaadin-grid-flow also includes frontend resources to provide custom styling in tests, test grid in a polymer template etc. In addition, it has data generators and helpers used.

Test Page

The next step is to select the integration test page which has the needed structure, and enhance it with new logic. For example, if contribution affects grid’s filtering logic, GridFilteringPage.java should be enhanced to test new behaviour. The name of the file helps to find the proper page. If structure of the page becomes much more complex or there is no file with suitable structure, new one can be created based on existing ones.

Note
Test Path
Remember to update @Route when creating a new file to avoid name conflicts.

Test

After selecting the page, new test should be added to existing files that are using the same route as @TestPath. For example, GridFilteringIT.java is using GridFilteringPage.java. If page was created instead, new correspondent test file should be created based on the existing ones.

Note
Test Path
Remember to update @TestPath when creating a new file to avoid name conflicts and ensure the tests are passing.

Inspiration from Existing Tests

Take a look onto the existing tests and search for the logic that’s needed to be implemented in newly created tests.

Examples worth mentioning:

959AB632-57BF-4AE0-B21C-7B022D439572