Contents
Overview
Helidon provides built-in test support for CDI testing in JUnit5.
Maven Coordinates
To enable Testing with JUnit add the following dependency to your project’s pom.xml (see Managing Dependencies).
<dependency>
<groupId>io.helidon.microprofile.testing</groupId>
<artifactId>helidon-microprofile-testing-junit5</artifactId>
<scope>test</scope>
</dependency>Usage
A test can be annotated with io.helidon.microprofile.testing.junit5.HelidonTest annotation to mark it as a CDI test. This annotation will start the CDI container before any test method is invoked, and stop it after the last method is invoked. This annotation also enables injection into the test class itself.
Usage - per method CDI container
A test can be annotated as follows:
@HelidonTest(resetPerTest = true)
This will change the behavior as follows:
A new CDI container is created for each test method invocation
annotations to add config, beans and extension can be added for each method in addition to the class
you cannot inject fields or constructor parameters of the test class itself (as a single instance is shared by more containers)
you can add
SeContaineras a method parameter of any test method and you will get the current container
Usage - configuration
In addition to the @AddConfig annotation, you can also use @Configuration to configure additional classpath properties config sources using configSources, and to mark that a custom configuration is desired. If @Configuration(useExisting=true), the existing (or default) MicroProfile configuration would be used. In this case it is important to set property mp.initializer.allow=true in order CDI container to start, when used with @HelidonTest. You can set up config in @BeforeAll method and register it with ConfigProviderResolver using MP Config APIs, and declare @Configuration(useExisting=true). Note that this is not compatible with repeatable tests that use method sources that access CDI, as we must delay the CDI startup to the test class instantiation (which is too late, as the method sources are already invoked by this time).
If you want to use method sources that use CDI with repeatable tests, please do not use @Configuration(useExisting=true)
Usage - added parameters and injection types
The following types are available for injection (when a single CDI container is used per test class):
WebTarget- a JAX-RS client’s target configured for the current hostname and port whenhelidon-micorprofile-serveris on the classpath
The following types are available as method parameters (in any type of Helidon tests):
WebTarget- a JAX-RS client’s target configured for the current hostname and port whenhelidon-micorprofile-serveris on the classpathSeContainer- the current container instance
API
The annotations described in this section are inherited (for the non-repeatable ones), and additive (for repeatable). So if you declare @DisableDiscovery on abstract class, all implementations will have discovery disabled, unless you annotate the implementation class with @DisableDiscovery(false). If you declare @AddBean on both abstract class and implementation class, both beans will be added.
In addition to this simplification, the following annotations are supported:
| Annotation | Usage |
|---|---|
@io.helidon.microprofile.testing.junit5.AddBean | Used to add one or more beans to the container (if not part of a bean archive, or when discovery is disabled) |
@io.helidon.microprofile.testing.junit5.AddExtension | Used to add one or more CDI extensions to the container (if not added through service loader, or when discovery is disabled) |
@io.helidon.microprofile.testing.junit5.AddConfig | Used to add one or more configuration properties to MicroProfile config without the need of creating a microprofile-config.properties file |
Used @io.helidon.microprofile.testing.junit5.DisableDiscovery | to disable automated discovery of beans and extensions |
Used @io.helidon.microprofile.testing.junit5.DisableDiscovery | to disable automated discovery of beans and extensions |
Used @io.helidon.microprofile.testing.junit5.AddJaxRs | add JaxRs support to the test class. Only used with
|
Examples
In the current example, Helidon container will be launched prior test. The Bean Discovery will be disabled. MyBean will be added to the test, so that it can be injected. ConfigCdiExtension will be enabled for this test. And finally, a configuration property will be added using @AddConfig annotation.
@HelidonTest
@DisableDiscovery
@AddBean(MyBean.class)
@AddExtension(ConfigCdiExtension.class)
@AddConfig(key = "app.greeting", value = "TestHello")
class TestExample {
@Inject
private MyBean myBean;
@Test
void testGreeting() {
assertThat(myBean, notNullValue());
assertThat(myBean.greeting(), is("TestHello"));
}
}- Start the Helidon container.
- Set disabled Bean Discovery for the current test class.
- Add
MyBeanto current context. - Add a configuration CDI extension to the current test.
- Add configuration properties.
- Inject
MyBeanas it is available in the CDI context. - Run rests.
To test @RequestScoped bean with JaxRs support:
RequestScoped bean@HelidonTest
@DisableDiscovery
@AddJaxRs
@AddBean(TestReqScopeDisabledDiscovery.MyController.class)
public class TestReqScopeDisabledDiscovery {
@Inject
private WebTarget target;
@Test
void testGet() {
String greeting = target.path("/greeting")
.request().get(String.class);
assertThat(greeting, is("Hallo!"));
}
@Path("/greeting")
@RequestScoped
public static class MyController {
@GET
public Response get() {
return Response.ok("Hallo!").build();
}
}
}- Start the Helidon container.
- Set disabled Bean discovery.
- Add JaxRs support to the current test class.
- Define a
RequestScopedbean.