Constructor Detail

Method Detail

• setup

  @JvmOverloads() final static Unit setup(Routes routes, UIFactory uiFactory, Set<Class<?>> lookupServices)

  Mocks Vaadin for the current test method:

  MockVaadin.setup(Routes().autoDiscoverViews("com.myapp"))

  The UI factory must provide a new, fresh instance of the UI, so that the tests start from a pre-known state. If you're using Spring and you're getting UI from the injector, you must reconfigure Spring to use prototype scope, otherwise an old UI from the UI scope or Session Scope will be provided.

  Sometimes you wish to provide a specific VaadinServletService, e.g. to override VaadinServletService.loadInstantiators and provide your own way of instantiating Views, e.g. via Spring or Guice. Please do that by extending MockVaadinServlet and overriding MockVaadinServlet.createServletService createServletService(DeploymentConfiguration). Please consult MockService on what methods you must override in your custom service. Alternatively, see MockSpringServlet (in the browserless-test-spring module) on how to extend your custom servlet and provide all necessary mocking code.

  Parameters:

  routes - all classes annotated with com.vaadin.flow.router.Route; use Routes.autoDiscoverViews to auto-discover all such classes.

  uiFactory - produces UI instances and sets them as current, by default simply instantiates MockedUI class.

  lookupServices - service classes to be provided to the lookup initializer

• setup

  @JvmOverloads() final static Unit setup(Routes routes, UIFactory uiFactory)

  Mocks Vaadin for the current test method:

  MockVaadin.setup(Routes().autoDiscoverViews("com.myapp"))

  The UI factory must provide a new, fresh instance of the UI, so that the tests start from a pre-known state. If you're using Spring and you're getting UI from the injector, you must reconfigure Spring to use prototype scope, otherwise an old UI from the UI scope or Session Scope will be provided.

  Sometimes you wish to provide a specific VaadinServletService, e.g. to override VaadinServletService.loadInstantiators and provide your own way of instantiating Views, e.g. via Spring or Guice. Please do that by extending MockVaadinServlet and overriding MockVaadinServlet.createServletService createServletService(DeploymentConfiguration). Please consult MockService on what methods you must override in your custom service. Alternatively, see MockSpringServlet (in the browserless-test-spring module) on how to extend your custom servlet and provide all necessary mocking code.

  Parameters:

  routes - all classes annotated with com.vaadin.flow.router.Route; use Routes.autoDiscoverViews to auto-discover all such classes.

  uiFactory - produces UI instances and sets them as current, by default simply instantiates MockedUI class.

• setup

  @JvmOverloads() final static Unit setup(Routes routes)

  Mocks Vaadin for the current test method:

  MockVaadin.setup(Routes().autoDiscoverViews("com.myapp"))

  The UI factory must provide a new, fresh instance of the UI, so that the tests start from a pre-known state. If you're using Spring and you're getting UI from the injector, you must reconfigure Spring to use prototype scope, otherwise an old UI from the UI scope or Session Scope will be provided.

  Sometimes you wish to provide a specific VaadinServletService, e.g. to override VaadinServletService.loadInstantiators and provide your own way of instantiating Views, e.g. via Spring or Guice. Please do that by extending MockVaadinServlet and overriding MockVaadinServlet.createServletService createServletService(DeploymentConfiguration). Please consult MockService on what methods you must override in your custom service. Alternatively, see MockSpringServlet (in the browserless-test-spring module) on how to extend your custom servlet and provide all necessary mocking code.

  Parameters:

  routes - all classes annotated with com.vaadin.flow.router.Route; use Routes.autoDiscoverViews to auto-discover all such classes.

• setup

  @JvmOverloads() final static Unit setup()

  Mocks Vaadin for the current test method:

  MockVaadin.setup(Routes().autoDiscoverViews("com.myapp"))

  The UI factory must provide a new, fresh instance of the UI, so that the tests start from a pre-known state. If you're using Spring and you're getting UI from the injector, you must reconfigure Spring to use prototype scope, otherwise an old UI from the UI scope or Session Scope will be provided.

  Sometimes you wish to provide a specific VaadinServletService, e.g. to override VaadinServletService.loadInstantiators and provide your own way of instantiating Views, e.g. via Spring or Guice. Please do that by extending MockVaadinServlet and overriding MockVaadinServlet.createServletService createServletService(DeploymentConfiguration). Please consult MockService on what methods you must override in your custom service. Alternatively, see MockSpringServlet (in the browserless-test-spring module) on how to extend your custom servlet and provide all necessary mocking code.

• setup

   final static Unit setup(UIFactory uiFactory, VaadinServlet servlet, Set<Class<?>> lookupServices)

  Use this method when you need to provide a completely custom servlet (e.g. SpringServlet). Do not forget to create a specialized service which works in mocked environment. See below for details on how to do this.

  The UI factory must provide a new, fresh instance of the UI, so that the tests start from a pre-known state. If you're using Spring and you're getting UI from the injector, you must reconfigure Spring to use prototype scope, otherwise an old UI from the UI scope or Session Scope will be provided.

  Parameters:

  uiFactory - produces UI instances and sets them as current, by default simply instantiates MockedUI class.

  servlet - allows you to provide your own implementation of VaadinServlet.

  lookupServices - service classes to be provided to the lookup initializer

• setupServlet

   final static VaadinServletService setupServlet(VaadinServlet servlet, Set<Class<?>> lookupServices)

  Initializes the given servlet and its service, but does NOT create a session, UI, or set any thread-locals. Call this when you need to share a single service across multiple independent sessions (multi-user testing).

  Returns:

  the initialized VaadinServletService

• closeCurrentUI

   final static Unit closeCurrentUI(Boolean fireUIDetach)

  Properly closes the current UI and fire the detach event on it. Does nothing if there is no current UI.

• tearDown

   final static Unit tearDown()

  Cleans up and removes the Vaadin UI and Vaadin Session. You can call this function in afterEach{} block, to clean up after the test. This comes handy when you want to be extra-sure that the next test won't accidentally reuse old UI, should you forget to call setup properly.

  You don't have to call this function though; setup will overwrite any current UI/Session instances with a fresh ones.

• fireSessionDestroyAndDrain

   final static Unit fireSessionDestroyAndDrain(VaadinSession session)

  Fires session-destroy listeners on session and drains pending VaadinSession.access tasks scheduled during destruction. The currentlyClosingSession flag is set for the duration so the afterSessionClose recreation hook (used by single-user setup) is suppressed — multi-user callers manage their own session lifecycle.

• createSessionObjects

   final static SessionObjects createSessionObjects(VaadinServletService service)

  Creates a new session, request and response for the given service, but does NOT set any thread-locals or create a UI.

  Use this when you need to create multiple independent sessions for multi-user testing. The caller is responsible for setting thread-locals (via VaadinSession.setCurrent, CurrentInstance, etc.) and for creating the UI via createUI.

  Parameters:

  service - the initialized Vaadin service (from setupServlet)

  Returns:

  the created session objects

• createUI

   final static Unit createUI(UIFactory uiFactory, VaadinSession session)

• clientRoundtrip

   final static Unit clientRoundtrip()

  Since Browserless Testing runs in the same JVM as the server and there is no browser, the boundaries between the client and the server become unclear. When looking into sources of any test method, it's really hard to tell where exactly the server request ends, and where another request starts.

  You can establish an explicit client boundary in your test, by explicitly calling this method. However, since that would be both laborous and error-prone, the default operation is that Browserless Testing pretends as if there was a client-server roundtrip before every component lookup via the _get/_find/_expectNone/_expectOne call. See TestingLifecycleHook for more details.

  Calls the following:

  • runUIQueue

  • StateTree.runExecutionsBeforeClientResponse which runs all blocks scheduled via UI.beforeClientResponse

  • cleanupDialogs

  If you'd like to test your ErrorHandler then take a look at runUIQueue instead.

• runUIQueue

  @JvmOverloads() final static Unit runUIQueue(Boolean propagateExceptionToHandler, VaadinSession session)

  Runs all tasks scheduled by UI.access.

  If VaadinSession.errorHandler is not set or propagateExceptionToHandler is false, any exceptions thrown from Commands scheduled via the UI.access will make this function fail. The exceptions will be wrapped in ExecutionException. Generally it's best to keep propagateExceptionToHandler set to false to make any exceptions fail the test; however if you're testing how your own custom VaadinSession.errorHandler responds to exceptions then set this parameter to true.

  Called automatically by clientRoundtrip which is by default called automatically from TestingLifecycleHook. You generally don't need to call this method unless you need to test your ErrorHandler.

  Parameters:

  propagateExceptionToHandler - defaults to false.

• runUIQueue

  @JvmOverloads() final static Unit runUIQueue(Boolean propagateExceptionToHandler)

  Runs all tasks scheduled by UI.access.

  If VaadinSession.errorHandler is not set or propagateExceptionToHandler is false, any exceptions thrown from Commands scheduled via the UI.access will make this function fail. The exceptions will be wrapped in ExecutionException. Generally it's best to keep propagateExceptionToHandler set to false to make any exceptions fail the test; however if you're testing how your own custom VaadinSession.errorHandler responds to exceptions then set this parameter to true.

  Called automatically by clientRoundtrip which is by default called automatically from TestingLifecycleHook. You generally don't need to call this method unless you need to test your ErrorHandler.

  Parameters:

  propagateExceptionToHandler - defaults to false.

• runUIQueue

  @JvmOverloads() final static Unit runUIQueue()

  Runs all tasks scheduled by UI.access.

  If VaadinSession.errorHandler is not set or propagateExceptionToHandler is false, any exceptions thrown from Commands scheduled via the UI.access will make this function fail. The exceptions will be wrapped in ExecutionException. Generally it's best to keep propagateExceptionToHandler set to false to make any exceptions fail the test; however if you're testing how your own custom VaadinSession.errorHandler responds to exceptions then set this parameter to true.

  Called automatically by clientRoundtrip which is by default called automatically from TestingLifecycleHook. You generally don't need to call this method unless you need to test your ErrorHandler.

• afterSessionClose

   final static Unit afterSessionClose(VaadinSession session, UIFactory uiFactory)

  Internal function, do not call directly.

  Only usable when you are providing your own implementation of VaadinSession. See MockVaadinSession on how to call this properly.

• fireSessionInit

   final static Unit fireSessionInit(VaadinService service, VaadinSession session, VaadinRequest request)

  Fires session init listeners on the given service. Java-friendly static wrapper for the internal extension function.

• fireServiceDestroy

   final static Unit fireServiceDestroy(VaadinService service)

  Fires service destroy listeners on the given service. Java-friendly static wrapper for the internal extension function.

• clearCurrentUI

   final static Unit clearCurrentUI()

  Clears the current UI from thread-locals without firing detach events. Useful for multi-user context where UIs are managed independently.

• clearLastNavigation

   final static Unit clearLastNavigation()

  Clears the lastNavigation ThreadLocal recorded by closeCurrentUI.

  closeCurrentUI records the closing UI's active view location into lastNavigation so that the immediately following createUI call (in the single-user reload / session-recreation flow) can restore that location on the new UI. Multi-user lifecycle close paths (BrowserlessUIContext.close) call closeCurrentUI without a matching createUI, so this method must be invoked afterwards to prevent the recorded location from leaking into the next unrelated createUI on the same thread (e.g. user.newWindow()).

• getUserAgent

   final String getUserAgent()

• setUserAgent

   final Unit setUserAgent(String value)

• getMockRequestFactory

   final Function1<MockHttpSession, MockRequest> getMockRequestFactory()

• setMockRequestFactory

   final Unit setMockRequestFactory(Function1<MockHttpSession, MockRequest> value)