Object MockVaadin

  • All Implemented Interfaces:

    
    public class MockVaadin
    
                        
    • Nested Class Summary

      Nested Classes 
      Modifier and Type Class Description
    • Constructor Summary

      Constructors 
      Constructor Description
    • Enum Constant Summary

      Enum Constants 
      Enum Constant Description
    • Method Summary

      Modifier and Type Method Description
      final static Unit setup(Routes routes, Function0<UI> 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.
      final static Unit setup(Routes routes, Function0<UI> 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.
      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.
      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.
      final static Unit setup(Function0<UI> uiFactory, VaadinServlet servlet, Set<Class<?>> lookupServices) Use this method when you need to provide a completely custom servlet (e.g.
      final Unit closeCurrentUI(Boolean fireUIDetach) Properly closes the current UI and fire the detach event on it.
      final static Unit tearDown() Cleans up and removes the Vaadin UI and Vaadin Session.
      final static Unit clientRoundtrip() Since UI Unit Testing runs in the same JVM as the server and there is no browser, the boundaries between the client and the server become unclear.
      final static Unit runUIQueue(Boolean propagateExceptionToHandler, VaadinSession session) Runs all tasks scheduled by UI.access.
      final static Unit runUIQueue(Boolean propagateExceptionToHandler) Runs all tasks scheduled by UI.access.
      final static Unit runUIQueue() Runs all tasks scheduled by UI.access.
      final static Unit afterSessionClose(VaadinSession session, Function0<UI> uiFactory) Internal function, do not call directly.
      final String getUserAgent() Change & call setup to set a different browser.
      final Unit setUserAgent(String userAgent) Change & call setup to set a different browser.
      final Function1<MockHttpSession, MockRequest> getMockRequestFactory() Creates MockRequest; override if you need to return a class that extends MockRequest and modifies its behavior.
      final Unit setMockRequestFactory(Function1<MockHttpSession, MockRequest> mockRequestFactory) Creates MockRequest; override if you need to return a class that extends MockRequest and modifies its behavior.
      • Methods inherited from class java.lang.Object

        clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait
    • Constructor Detail

    • Method Detail

      • setup

        @JvmOverloads() final static Unit setup(Routes routes, Function0<UI> 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 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, Function0<UI> 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 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 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 on how to extend your custom servlet and provide all necessary mocking code.

      • setup

         final static Unit setup(Function0<UI> 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
      • closeCurrentUI

         final 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.

      • clientRoundtrip

         final static Unit clientRoundtrip()

        Since UI Unit 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 UI Unit 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:

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

      • afterSessionClose

         final static Unit afterSessionClose(VaadinSession session, Function0<UI> 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.

      • getUserAgent

         final String getUserAgent()

        Change & call setup to set a different browser.

        The default is Firefox 94 on Ubuntu Linux.

      • setUserAgent

         final Unit setUserAgent(String userAgent)

        Change & call setup to set a different browser.

        The default is Firefox 94 on Ubuntu Linux.