Vaadin Browserless Use-Case Tests

Browserless tests run a Vaadin Flow UI inside the test JVM: no browser and no HTTP server, but real views, real listeners, navigation, and real Spring or Quarkus beans (or mocks). A test runs in milliseconds and gives the same result every time, so it is the feedback loop to run after every UI change. They sit between unit tests of services and real-browser tests, and they are the layer that proves the use cases work.

The API this skill uses — application, user, and window contexts with locators — arrived in Vaadin 25.2, after most training data. Check the project's Vaadin version first. Before writing a call you are not sure of, look it up with the Vaadin MCP: get_java_symbol for BrowserlessUIContext or a *Locator class, and search_vaadin_docs for the guides, with vaadin_version set to the project's version.

The rule: a test reads as its use case

Base every test on a use case: who does what, and what should happen. Write it so that someone who has never seen the code — a product owner, a new team member — can read the test method aloud and recognise the use case. The tests then double as the specification.

@Test
void boaterWhoLosesTheRaceBooksAnotherBerth() {
    Boater alice = new Boater("S/Y Alice");
    Boater bob = new Boater("S/Y Bob");

    alice.books("B12");
    bob.books("B12");
    assertTrue(bob.wasToldThat("B12 was just taken"));