Testing
These guides show you how to test the server-side behavior of Flow views using browserless tests. Start by choosing the setup for your application framework, then choose a guide for the behavior you need to verify.
Browserless tests run against Java components without a browser. Use browser-based tests when you need to verify rendering, client-side behavior, or real browser interactions. See the testing reference for a comparison of the approaches.
Choosing What to Test
Each layer of your application is tested in its own way. The following table shows where to find guidance for each:
| What you test | Kind of test | Guidance |
|---|---|---|
Application services and their rules, including access control | Spring integration tests that call the service | Test the Service in the tutorial, Testing Method Security, and Testing Record Rules |
Queries, migrations, and the database schema | Integration tests against the same database as in production | Add Testcontainers, and Testcontainers in the Spring Boot documentation |
Flow views | Browserless tests | The guides listed below |
Rendering, client-side behavior, and the whole application in a browser | End-to-end tests |
Service and browserless tests are fast and don’t need a browser, so they can cover most of your application, including its use cases from start to finish. Keep end-to-end tests for what only a browser can show, as described in Keep a Thin Layer of Browser Tests.
Browserless tests can’t test React views, because React views run in the browser. Test the browser-callable services of a React view like any other application service, and the view itself with end-to-end tests, or with the JavaScript tools described in Testing in the Hilla reference.
To run the tests on every change, see Build on CI.
Keep a Thin Layer of Browser Tests
Browserless tests prove behavior, not rendering. They can’t show that:
-
the theme and the CSS look right,
-
the client-side JavaScript of a component works,
-
the layout works in real browsers and at different screen sizes, or
-
add-ons and custom components render.
Keep a few end-to-end tests in a real browser for these, also as a safety net when you upgrade Vaadin or an add-on. Typical smoke tests check that:
-
the most important views open,
-
custom components and add-ons render,
-
the browser console shows no JavaScript errors,
-
the login flow works, and
-
each kind of gesture, such as drag and drop, reaches the server-side code that handles it; see Design Gestures for Testing.
Don’t repeat the use cases in the browser tests: the rules behind them belong in the faster browserless tests. A component with client-side code of its own also needs browser tests for that code, in the component’s own module.
Guides
- Browserless Testing
- Choose the browserless test setup for Spring Boot, Java EE/CDI, Quarkus, or plain Java, then test your Flow views.
3E1E2938-89FF-4EFD-9EE2-658369A06F3A