Docs

Docs

Test Environment and Lifecycle

Browserless test base classes, environment lifecycle, route scanning, navigation, and simulated server round trips.

Browserless tests create the Vaadin service, session, and UI in the test JVM. The standard base-class setup initializes a new environment before each test method and tears it down afterwards. Custom setup, such as CDI integration, replaces initialization while retaining the JUnit lifecycle hooks. JUnit’s @TestInstance(PER_CLASS) changes the test-instance lifecycle; it does not share the Vaadin environment.

Base Classes and Framework Integration

Base Class

Integration

BrowserlessTest

Plain Java, provided by browserless-test-junit6.

An application-owned CDI subclass of BrowserlessTest

Weld and CdiVaadinServlet; see CDI Test Integration.

SpringBrowserlessTest

Spring application context and dependency injection, provided by browserless-test-spring.

QuarkusBrowserlessTest

Quarkus test framework and dependency injection, provided by browserless-test-quarkus.

The JUnit extensions provide composition-based setup for plain Java tests. The application context API supports multiple users and windows.

Route Scanning

By default, browserless tests scan the classpath for routes and error views. @ViewPackages(classes = MyView.class) restricts scanning to the packages of the supplied classes and their sub-packages. @ViewPackages(packages = "com.example.views") accepts package names instead. Both attributes may be combined. An empty @ViewPackages restricts scanning to the test class’s package and its sub-packages.

In Spring tests, @SpringBootTest loads the full application context; @ContextConfiguration selects a narrower configuration. See Spring Security Integration for access-control initialization when using a reduced context.

With the default environment setup, the loaded view is the root view. The custom CDI setup registers routes after initialization and navigates explicitly in the test.

To navigate to another registered view, use the navigate() methods provided by the base class:

  • For a normal view with only a path defined

    navigate(MyView.class)

    navigate("myView", MyView.class)

  • For a view with HasUrlParameter

    navigate(MyParam.class, "parameter")

    navigate("myParam/parameter", MyParam.class)

  • For a view with URL template @Route("template/:param")

    navigate(Template.class, Collections.singletonMap("param", PARAMETER))

    navigate("template/myParam", Template.class)

  • For a location that carries a query string, a fragment, or both

    navigate("myParam/parameter?tab=history&page=2", MyParam.class)

    The location is split up the same way the browser address bar does it, so the query parameters reach the view through the navigation event. A location consisting only of a fragment, such as "#details", identifies a place within the current page rather than a route, so it leaves the current view in place.

All navigation methods return the instantiated view, so that its fields can be used directly for testing.

Note
 Navigation by location string takes in the view class, so that the initialized view can be automatically validated to be the expected one.

You can also retrieve the current view at any time with getCurrentView():

Source code
Java
HasElement view = getCurrentView();

Simulating Keyboard Shortcuts

Use fireShortcut() to simulate keyboard shortcuts registered with Vaadin’s shortcut API:

Source code
Java
// Simulate pressing Enter
fireShortcut(Key.ENTER);

// Simulate Ctrl+S
fireShortcut(Key.KEY_S, KeyModifier.CONTROL);

Server Round Trips

roundTrip() processes pending client-server communication in the simulated environment. It does not start a browser or execute client-side JavaScript. Signal task processing is described separately in Signal Test Environment.

For worked examples, choose your framework in Browserless Testing.

Framework-Specific Timing and Configuration

See Environment Differences for Spring injection, session-scoped beans, and authentication timing. See CDI Test Integration for the custom Weld lifecycle. For standard per-test properties, feature flags, and Lookup services, see Test Configuration and the configuration guide.

0262B190-4113-4A35-BD70-F727FB2F2AD5

Updated –