Package com.vaadin.browserless

Class BaseBrowserlessTest

java.lang.Object
com.vaadin.browserless.BaseBrowserlessTest
Direct Known Subclasses:
BrowserlessTest, QuarkusBrowserlessTest, SpringBrowserlessTest
public abstract class BaseBrowserlessTest extends Object
Base class for browserless tests. Provides methods to set up and clean a mocked Vaadin environment. The class allows scan classpath for routes and error views. Subclasses should typically restrict classpath scanning to a specific packages for faster bootstrap, by using ViewPackages annotation. If the annotation is not present a full classpath scan is performed For internal use only. May be renamed or removed in a future release.
Since:
1.0
See Also:

  • Constructor Details

    • BaseBrowserlessTest

      public BaseBrowserlessTest()

  • Method Details

    • discoverRoutes

      protected com.vaadin.browserless.internal.Routes discoverRoutes()

    • discoverRoutes

      protected static com.vaadin.browserless.internal.Routes discoverRoutes(Set<String> packageNames)
      Discover and return Routes for mocked Vaadin core system.
      Returns:
      Routes
      See Also:

    • initVaadinEnvironment

      protected void initVaadinEnvironment()
      Create mocked Vaadin core obects, such as session, servlet populated with Routes, UI etc. for testing and find testers for the components.

    • allLookupServices

      protected final Set<Class<?>> allLookupServices()
      Gets the lookup services to register, combining the ones required by the framework integration, the ones provided by the deprecated lookupServices() hook, and the ones declared by the test configuration. For internal use only.
      Returns:
      the set of services implementation classes, never null.

    • allLookupServices

      protected final Set<Class<?>> allLookupServices(BrowserlessConfiguration configuration)
      Same as allLookupServices(), but for a configuration that has already been resolved. testConfiguration() is an overridable hook, so an override rebuilding the configuration on every call would otherwise do the work twice, and a non deterministic one could register services that do not belong to the configuration actually applied to the environment. Resolve the configuration once and pass it to both this method and MockVaadin.setup(). For internal use only.
      Parameters:
      configuration - the configuration to read the lookup services from, not null
      Returns:
      the set of services implementation classes, never null.

    • initSignalsSupport

      protected void initSignalsSupport()

    • scanTesters

      protected void scanTesters()
      Scan testers and populate testers map with them. The test method can find appropriate test based on testers map.
      See Also:

    • scanPackages

      protected Set<String> scanPackages()

    • cleanVaadinEnvironment

      protected void cleanVaadinEnvironment()
      Tears down mocked Vaadin.

    • lookupServices

      @Deprecated(since="25.3") protected Set<Class<?>> lookupServices()
      Deprecated.
      since 25.3, declare the services with BrowserlessTestConfig.lookupServices() or by overriding testConfiguration() instead. Overrides of this method are still honored.
      Gets the services implementations to be used to initialized Vaadin Lookup. Default implementation returns an empty Set. Override this method to provide custom Vaadin services, such as InstantiatorFactory, ResourceProvider, etc. Since 25.3 the services required by the Spring and Quarkus integrations are contributed by frameworkLookupServices() instead, and are always registered. An override of this method therefore adds to them and can no longer replace one of them, for example to swap the Spring SpringSecurityRequestCustomizer; override frameworkLookupServices() in a framework specific base class for that.
      Returns:
      set of services implementation classes, never null.

    • frameworkLookupServices

      protected Set<Class<?>> frameworkLookupServices()
      Gets the services implementations required by the framework integration to initialize the Vaadin Lookup, for example the Spring or Quarkus lookup initializers. These services are always registered, regardless of the test configuration, so that a test customizing testConfiguration() cannot accidentally break the framework integration. Meant to be overridden by framework specific base classes only; tests should declare their own services with BrowserlessTestConfig.lookupServices().
      Returns:
      set of services implementation classes, never null.
      Since:
      25.3

    • testConfiguration

      protected BrowserlessConfiguration testConfiguration()
      Gets the custom Vaadin configuration, such as application properties and feature flags, to apply to the mock Vaadin environment. Default implementation returns the configuration declared by the BrowserlessTestConfig annotations present on the test class and on the current test method, if any. Override this method to provide the configuration programmatically, potentially on top of the declared one. 
       @Override
 protected BrowserlessConfiguration testConfiguration() {
     return BrowserlessConfiguration.builder()
             .withConfiguration(super.testConfiguration())
             .withFeatureFlags("myExperimentalFeature").build();
 }
      Returns:
      the configuration to apply, never null.
      Since:
      25.3
      See Also:

    • fireShortcut

      public void fireShortcut(Key key, KeyModifier... modifiers)
      Simulates a keyboard shortcut performed on the browser.
      Parameters:
      key - Primary key of the shortcut. This must not be a KeyModifier.
      modifiers - Key modifiers. Can be empty.

    • getCurrentView

      public HasElement getCurrentView()
      Get the current view instance that is shown on the ui.
      Returns:
      current view

    • internalWrap

      protected static <T extends ComponentTester<Y>, Y extends Component> T internalWrap(Y component)

    • internalWrap

      protected static <T extends ComponentTester<Y>, Y extends Component> T internalWrap(Class<T> wrap, Y component)

    • test

      public <T extends ComponentTester<Y>, Y extends Component> T test(Y component)
      Wrap component with ComponentTester best matching component type.
      Type Parameters:
      T - tester type
      Y - component type
      Parameters:
      component - component to get test wrapper for
      Returns:
      component in wrapper with test helpers

    • test

      public <T extends ComponentTester<Y>, Y extends Component> T test(Class<T> tester, Y component)
      Wrap component in given ComponentTester.
      Type Parameters:
      T - tester type
      Y - component type
      Parameters:
      tester - test wrapper to use
      component - component to wrap
      Returns:
      initialized test wrapper for component

    • find

      public <T extends Component> ComponentQuery<T> find(Class<T> componentType)
      Gets a query object for finding a component inside the UI

      The query walks the server-side component tree. A component that another component renders per item, such as the component a ComponentRenderer column renders for a grid row, is rendered into the column and not into the tree, and the content of an overlay, such as a context menu, is attached only while the overlay is open. Neither is reachable this way, and the lookup returns an empty result rather than failing, so reach those components through the owning component tester instead: GridTester.getCellComponent(row, column) for grid cells, ContextMenuTester.open() and then clickItem(...) for a context menu, and GridTester.contextMenu(row).open() for a grid context menu.

      Type Parameters:
      T - the type of the component(s) to search for
      Parameters:
      componentType - the type of the component(s) to search for
      Returns:
      a query object for finding components
      Since:
      1.1

    • find

      public <T extends Component> ComponentQuery<T> find(Class<T> componentType, Component fromThis)
      Gets a query object for finding a component nested inside the given component.

      Searches the same server-side component tree as find(Class), see there for what that tree does not contain.

      Type Parameters:
      T - the type of the component(s) to search for
      Parameters:
      componentType - the type of the component(s) to search for
      fromThis - component used as starting element for search.
      Returns:
      a query object for finding components
      Since:
      1.1

    • findInView

      public <T extends Component> ComponentQuery<T> findInView(Class<T> componentType)
      Gets a query object for finding a component inside the current view

      Searches the same server-side component tree as find(Class), see there for what that tree does not contain.

      Type Parameters:
      T - the type of the component(s) to search for
      Parameters:
      componentType - the type of the component(s) to search for
      Returns:
      a query object for finding components
      Since:
      1.1

    • $

      @Deprecated(since="1.1", forRemoval=true) public <T extends Component> ComponentQuery<T> $(Class<T> componentType)
      Deprecated, for removal: This API element is subject to removal in a future version.
      since 1.1, for removal in 26.0; use find(Class) instead.
      Gets a query object for finding a component inside the UI.
      Type Parameters:
      T - the type of the component(s) to search for
      Parameters:
      componentType - the type of the component(s) to search for
      Returns:
      a query object for finding components

    • $

      @Deprecated(since="1.1", forRemoval=true) public <T extends Component> ComponentQuery<T> $(Class<T> componentType, Component fromThis)
      Deprecated, for removal: This API element is subject to removal in a future version.
      since 1.1, for removal in 26.0; use find(Class, Component) instead.
      Gets a query object for finding a component nested inside the given component.
      Type Parameters:
      T - the type of the component(s) to search for
      Parameters:
      componentType - the type of the component(s) to search for
      fromThis - component used as starting element for search.
      Returns:
      a query object for finding components

    • $view

      @Deprecated(since="1.1", forRemoval=true) public <T extends Component> ComponentQuery<T> $view(Class<T> componentType)
      Deprecated, for removal: This API element is subject to removal in a future version.
      since 1.1, for removal in 26.0; use findInView(Class) instead.
      Gets a query object for finding a component inside the current view.
      Type Parameters:
      T - the type of the component(s) to search for
      Parameters:
      componentType - the type of the component(s) to search for
      Returns:
      a query object for finding components

    • roundTrip

      protected static void roundTrip()
      Simulates a server round-trip, flushing pending component changes.

    • runPendingSignalsTasks

      protected final boolean runPendingSignalsTasks()
      Processes all pending Signals tasks with a default max wait time of 100 milliseconds. This is a convenience method for tests that need to wait for asynchronous Signal effects to complete.

      When Signals are triggered from background threads or non-UI contexts, their effects are enqueued to simulate asynchronous processing. This method allows tests to flush and execute all such pending tasks synchronously, ensuring deterministic behavior in unit tests.

      If any VaadinSession lock is held by the current thread, it is temporarily released during the wait to allow background threads to acquire the lock and enqueue tasks.

      Confirmation of a write to a shared signal (for example SharedValueSignal or SharedListSignal) is dispatched through the same queue. The new value is visible immediately through peek(), but the SignalOperation returned by the write only completes once the queued confirmation task has been run by this method. Blocking on operation.result().get() without draining the queue first never completes, because the confirmation task can only run on the thread that calls this method: 

      
 var operation = tickets.insertLast("a ticket");
 runPendingSignalsTasks();
 assertTrue(operation.result().join().successful());
      Returns:
      true if any pending Signals tasks were processed.
      See Also:

    • runPendingSignalsTasks

      protected final boolean runPendingSignalsTasks(long maxWaitTime, TimeUnit unit)
      Processes all pending Signals tasks, waiting up to the specified timeout for tasks to arrive. This method is essential for testing asynchronous Signal effects triggered from background threads or non-UI contexts.

      When Signals are triggered from background threads or non-UI contexts, their effects are enqueued to simulate asynchronous processing. This method allows tests to flush and execute all such pending tasks synchronously, ensuring deterministic behavior in unit tests.

      The timeout applies only to waiting for the first task to arrive. Once the first task is found, all remaining tasks in the queue are processed immediately without additional waiting. If any VaadinSession lock is held by the current thread, it is temporarily released during the wait to allow background threads to acquire the lock and enqueue tasks.

      Parameters:
      maxWaitTime - the maximum time to wait for the first task to arrive in the given time unit. If <= 0, returns immediately if no tasks are available.
      unit - the time unit of the timeout value
      Returns:
      true if any pending Signals tasks were processed.
      See Also:

    • testingEngine

      protected abstract String testingEngine()
      Gets the name of the Test Engine that is able to run the base class implementation. The Test Engine name is reported in the exception thrown when the Vaadin environment is not set up correctly.
      Returns:
      name of the Test Engine.