Describe your motivation
The flow/testing/browserless section on docs.vaadin.com already covers the mechanics well (Getting Started, Component Testers, Querying Components, Spring Security, Snapshots, Non-Spring Projects, Quarkus, Optimizing Tests, Migrating from UI Unit Testing). The comparison with end-to-end testing is also there, briefly.
What is missing in 25.2 is per-feature guidance for the new platform APIs:
-
Signals testing patterns. The current docs do not show how to assert against a Signal-driven UI in a browserless test. Patterns like "set a ValueSignal, then assert the component bound through Signal.computed / Signal.effect updates synchronously" are exactly the kind of thing the harness is good at, but there is no page on it.
-
GeolocationSimulator and the Geolocation testing story. com.vaadin.flow.component.geolocation.GeolocationSimulator exists and works inside browserless tests via GeolocationSimulator.current().grantPermission() plus setLocation(...). None of this is documented today; users have to read the source of vaadin-map-flow and the simulator class to discover it.
-
AI Components testing. AIOrchestrator and friends require a ChatClient.Builder and an LLMProvider. Without a documented test double for these (or a recipe for mocking Spring AI), it is currently impossible to ship browserless tests for views that depend on the AI components.
-
The decision tree per feature. The existing comparison section explains the broad strokes ("browserless is fast, TestBench is the real browser") but does not enumerate, for each 25.2 feature, which tool to pick. Clipboard needs TestBench because there is no simulator. CollaborationEngine real-time sync needs TestBench because the WebSocket dispatch is browser-only. Geolocation should default to browserless because the simulator exists. MasterDetailLayout, Sliders, MessageList attachments all run fine in browserless. A short table would close this gap.
Describe the solution you'd like
Three concrete additions, in order of value:
-
A new sub-page "Testing Signals" under /docs/latest/flow/testing/browserless/ covering: ValueSignal / ListSignal / Signal.computed / Signal.effect / the bind* family, with one or two minimal-repro tests that show the synchronous propagation.
-
A new sub-page "Testing Geolocation" documenting GeolocationSimulator.current(), grantPermission(), setLocation(lat, lon, accuracy), and requests(), plus the BrowserlessExtension boilerplate needed to use them.
-
An expansion of the existing comparison section with a per-feature table: each row a 25.2 API or feature, columns "browserless", "TestBench", "blocked / needs test double". Roughly 12 to 15 rows.
A standalone "Testing AI Components" page would be valuable too.
Describe your motivation
The
flow/testing/browserlesssection on docs.vaadin.com already covers the mechanics well (Getting Started, Component Testers, Querying Components, Spring Security, Snapshots, Non-Spring Projects, Quarkus, Optimizing Tests, Migrating from UI Unit Testing). The comparison with end-to-end testing is also there, briefly.What is missing in 25.2 is per-feature guidance for the new platform APIs:
Signals testing patterns. The current docs do not show how to assert against a Signal-driven UI in a browserless test. Patterns like "set a ValueSignal, then assert the component bound through
Signal.computed/Signal.effectupdates synchronously" are exactly the kind of thing the harness is good at, but there is no page on it.GeolocationSimulatorand theGeolocationtesting story.com.vaadin.flow.component.geolocation.GeolocationSimulatorexists and works inside browserless tests viaGeolocationSimulator.current().grantPermission()plussetLocation(...). None of this is documented today; users have to read the source ofvaadin-map-flowand the simulator class to discover it.AI Components testing.
AIOrchestratorand friends require aChatClient.Builderand anLLMProvider. Without a documented test double for these (or a recipe for mocking Spring AI), it is currently impossible to ship browserless tests for views that depend on the AI components.The decision tree per feature. The existing comparison section explains the broad strokes ("browserless is fast, TestBench is the real browser") but does not enumerate, for each 25.2 feature, which tool to pick. Clipboard needs TestBench because there is no simulator. CollaborationEngine real-time sync needs TestBench because the WebSocket dispatch is browser-only. Geolocation should default to browserless because the simulator exists. MasterDetailLayout, Sliders, MessageList attachments all run fine in browserless. A short table would close this gap.
Describe the solution you'd like
Three concrete additions, in order of value:
A new sub-page "Testing Signals" under
/docs/latest/flow/testing/browserless/covering: ValueSignal / ListSignal / Signal.computed / Signal.effect / thebind*family, with one or two minimal-repro tests that show the synchronous propagation.A new sub-page "Testing Geolocation" documenting
GeolocationSimulator.current(),grantPermission(),setLocation(lat, lon, accuracy), andrequests(), plus theBrowserlessExtensionboilerplate needed to use them.An expansion of the existing comparison section with a per-feature table: each row a 25.2 API or feature, columns "browserless", "TestBench", "blocked / needs test double". Roughly 12 to 15 rows.
A standalone "Testing AI Components" page would be valuable too.