Annotation Interface BrowserlessTestConfig


@Retention(RUNTIME) @Target({TYPE,METHOD}) @Documented @Inherited public @interface BrowserlessTestConfig
Applies a custom Vaadin configuration to a single test class or test method.

Both Vaadin application properties (also known as init parameters) and feature flags are scoped to the mock Vaadin environment created for the annotated test, so they neither require a @BeforeEach/ @AfterEach pair to set and reset system properties, nor leak into other tests.

 @BrowserlessTestConfig(applicationProperties = "devmode.sessionSerialization.enabled=true", featureFlags = "myExperimentalFeature")
 class MyViewTest extends BrowserlessTest {
 }
 
The annotation can be placed both on the test class and on a test method. In that case the two configurations are merged, and values declared on the method win over the ones declared on the class.

Every annotation the test inherits is merged in as well, rather than being shadowed by the nearest one: a superclass declaring part of the configuration for a family of tests keeps contributing it, and so does the enclosing class of a @Nested test. The closer the declaration is to the test method, the higher it ranks, so the order is method, test class, superclasses from the nearest up, then enclosing classes from the innermost out. Lookup services are the exception: they accumulate instead of being replaced.

 @BrowserlessTestConfig(applicationProperties = "base.property=fromBase")
 abstract class AbstractViewTest extends BrowserlessTest {
 }

 @BrowserlessTestConfig(featureFlags = "myExperimentalFeature")
 class CartViewTest extends AbstractViewTest {
     // both base.property and myExperimentalFeature apply
 }
 

Method level configuration requires an environment that is created for each test method. It is therefore not supported when the Vaadin environment is shared by all the tests in the class, for example with BrowserlessClassExtension, or with a base class test whose initVaadinEnvironment() override is not a @BeforeEach; in those cases the annotation must be placed on the test class.

@TestInstance(Lifecycle.PER_CLASS) alone only changes how the test instance is created, not when the Vaadin environment is: a base class test still builds it in a @BeforeEach, so method level configuration keeps working.

Since:
25.3
See Also:
  • Optional Element Summary

    Optional Elements
    Modifier and Type
    Optional Element
    Description
    Vaadin application properties (init parameters) to apply to the mock Vaadin environment created for the annotated test.
    Vaadin feature flags to enable or disable for the annotated test, overriding the values potentially defined in the vaadin-featureflags.properties file or in system properties.
    Class<?>[]
    Service implementation classes to be used to initialize the Vaadin Lookup for the annotated test, such as InstantiatorFactory or ResourceProvider implementations.
  • Element Details

    • featureFlags

      String[] featureFlags
      Vaadin feature flags to enable or disable for the annotated test, overriding the values potentially defined in the vaadin-featureflags.properties file or in system properties.

      Each entry is either the identifier of the feature, to enable it, or an id=true|false pair, for example featureFlags = { "featureToEnable", "featureToDisable=false" }.

      Returns:
      the feature flags to override, never null
      Default:
      {}
    • applicationProperties

      String[] applicationProperties
      Vaadin application properties (init parameters) to apply to the mock Vaadin environment created for the annotated test.

      Each entry is a name=value pair, for example applicationProperties = "devmode.sessionSerialization.enabled=true". Values are split on the first = character, so a value may itself contain =.

      Returns:
      the application properties to apply, never null
      Default:
      {}
    • lookupServices

      Class<?>[] lookupServices
      Service implementation classes to be used to initialize the Vaadin Lookup for the annotated test, such as InstantiatorFactory or ResourceProvider implementations.

      Unlike application properties and feature flags, lookup services declared on the test class and on the test method are accumulated rather than replaced: a test method can add a service, but cannot remove one declared by its test class.

      Returns:
      the lookup service implementation classes, never null
      Default:
      {}