Weld meets JUnit 5

2017-12-19   junit , testing , weld-se   Matej Novotny

In this article I want to bring weld-junit into light. You might have heard about or, better still, used our extension for JUnit 4 which has been around for some time now. But after getting ourselves acquainted with JUnit 5, we decided we should create another one for JUnit 5. In the sections below I will try to introduce the basic usage and ideas behind it, for more in depth information, you can glance the readme file residing directly in the repository.

GAV Coordinates

Here are group and artifact IDs you need to grab the artifact for Maven projects:

<dependency>
  <groupId>org.jboss.weld</groupId>
  <artifactId>weld-junit-parent</artifactId>
  <version>${weld.junit.version}</version>
</dependency>

First Steps

You can use the extension as you would any other in JUnit 5, via @ExtendWith from JUnit library along with the name of our extension - org.jboss.weld.junit5.WeldJunit5Extension. Alternatively, there is a shorter annotation @org.jboss.weld.junit5.EnableWeld. Both of these can be used on class and method level.

Hence your test could look like this:

[ source, java ]

@EnableWeld
public class InjectionWithWeldTest {

  @Inject
  BarBean beanAsField;

  @Test
  public void testThatItWorks(FooBean beanAsParam) {
    assertNotNull(beanAsParam);
    beanAsParam.ping();
    assertNotNull(beanAsField);
    beanAsField.ping();
  }

}

Behind the scenes, Weld will bootstrap SE container for each test container invocation and tear it down afterwards (works for both, per-method and per-class lifecycle). As you might have guessed, Weld will also automatically inject into any fields within the test class which you annotated with @Inject. Furthermore, it will attempt to resolve parameters in your test methods in very much the same way. But beware, by default Weld will only scan classes from within the test package! With this in mind, you can play around with beans to your liking.

Dude, Where Is My Container?

Good point, when working with Weld SE you normally have the power to customize container bootstrap and, once running, to query it for beans, fire events and so on. And you shall retain that right!

Only you are going to need a public field with type org.jboss.weld.junit5.WeldInitiator which you annotate with @org.jboss.weld.junit5.WeldSetup. This class has a bunch of static method which will allow you to customize the boostrap and it also works as a handle to grasp the WeldContainer running below.

Too much talk, not enough code, so here we go:

[ source, java ]

@ExtendWith(WeldJUnit5Extension.class)
public class WeldJUnit5CustomizedTest {

  @WeldSetup
  public WeldInitiator weld = WeldInitiator.of(WeldInitiator.createWeld()
                                           .alternatives(FooAlternative.class)
                                           .beanClasses(Foo.class, FooAlternative.class)
                                           .enableInterceptors(MyInterceptor.class));

  @Inject
  Foo bean; // this will be FooAlternative in the end

  @Test
  public void testWeldContainerUsage() {
    weld.event().select(MyPayload.class).fire(new MyPayload());
    weld.select(Foo.class).isResolvable();
  }
}

Help, I Am Stuck With JUnit 4

No problems, we got you covered, check out our JUnit 4 extension.

They are both very similar and easy to master. The only notable difference is that in JUnit 4 you always need the initiator class - org.jboss.weld.junit4.WeldInitiator.

What If I Would Like To…​

If you’re stuck and need a helping hand, we are listening on the usual channels - mailing list, Stack Overflow, Gitter, IRC, GitHub.

It might also be the case that we forgot about something quite important, so don’t hesitate to reach to us through those channels, or open a GitHub issue straight away. We are happy for any kind of feedback we can get.