Testing

This section documents the current Vaadin release line — Vaadin 24 LTS / 25.x, Java 17+, Spring Boot 3 / Jakarta EE 10 — as published at the official Vaadin documentation, which is the reference these pages are written and verified against. No specific patch version is pinned. Flow (server-side Java) is the authoring style used throughout, with Hilla / React shown where it differs; Vaadin 7 and the pre-Flow architecture appear only as migration contrast.

This content was generated with the assistance of AI and should be verified against the official documentation before being relied on in production, since Vaadin ships major releases roughly twice a year and its ecosystem iterates.

This section’s bibliography lists the reference material consulted while preparing these pages.

Vaadin has two test layers: fast browserless UI unit tests that instantiate views in the JVM, and end-to-end tests that drive a real browser. This page follows the Testing documentation.

UI unit tests (browserless)

vaadin-testbench-unit renders a view and its components server-side — no browser, no HTTP — so tests run at unit-test speed. Extend UIUnitTest and point @ViewPackages at the code under test:

<dependency>
  <groupId>com.vaadin</groupId>
  <artifactId>vaadin-testbench-unit</artifactId>
  <scope>test</scope>
</dependency>
@ViewPackages(packages = "com.example.views")
class CustomerViewTest extends UIUnitTest {

    @Test
    void savingShowsANotification() {
        CustomerView view = navigate(CustomerView.class);

        $(TextField.class).withCaption("Name").first().setValue("Ada");
        $(Button.class).withText("Save").first().click();

        assertEquals("Saved", $(Notification.class).last().getText());
    }
}

navigate(…​) performs a real navigation (running BeforeEnter observers and security checks); $(Type.class) queries the component tree with filters like withText, withCaption, withId; test(component) wraps a component in a tester that simulates user actions (click(), setValue(), _click() for the raw event). This module is not commercial — it ships under the same licence as the framework core. See UI unit testing.

End-to-end tests with TestBench

TestBench is Vaadin’s commercial Selenium-based tool (see UI Component Libraries). It drives a real browser and adds a fluent, component-aware element query API and pixel screenshot comparison:

@BrowserTest
class CustomerViewIT extends TestBenchTestCase {

    @BeforeEach
    void open() { getDriver().get("http://localhost:8080/customers"); }

    @Test
    void filtersTheGrid() {
        TextFieldElement filter = $(TextFieldElement.class).id("filter");
        filter.setValue("Ada");

        GridElement grid = $(GridElement.class).first();
        assertEquals("Ada Lovelace", grid.getCell(0, 0).getText());
    }
}

$(GridElement.class), .id(…​), .waitForFirst() and compareScreen("customers") are the core API. Run these against a started application (for example in the Maven verify phase).

Playwright and Selenium

You can also test a running Vaadin app with plain Playwright for Java or raw Selenium — Vaadin exposes stable id and component structure for selectors. TestBench adds the component-typed element classes and screenshot tooling on top; the plain tools are the free option.

Load testing

The client-server protocol replays well: record a session and drive it with a load tool (Gatling is commonly used). See Load testing for capturing and parameterising the sync messages.

With Spring

Combine a UI unit test with a Spring context to exercise the real services and repositories:

@SpringBootTest
@ViewPackages(packages = "com.example.views")
class CustomerViewSpringTest extends UIUnitTest {
    // injected Spring beans are used by the view under test
}

See also