News - tagged as "testing"

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:


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 ]

    public class InjectionWithWeldTest {
      BarBean beanAsField;
      public void testThatItWorks(FooBean beanAsParam) {

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 ]

    public class WeldJUnit5CustomizedTest {
      public WeldInitiator weld = WeldInitiator.of(WeldInitiator.createWeld()
                                               .beanClasses(Foo.class, FooAlternative.class)
      Foo bean; // this will be FooAlternative in the end
      public void testWeldContainerUsage() {
        weld.event().select(MyPayload.class).fire(new MyPayload());;

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.

Arquillian container Weld 2.0.0.Beta1 released!

2016-7-21   arquillian , testing   Tomas Remes

We are pleased to announce a release of embedded Arquillian container adapter for Weld. This container has deserved some love for really long time. We tried to refactor it and introduced new master branch which now corresponds to the 2.0.0.x version stream. The original master was branched in 1.0. There is no more any arquillian-weld-ee-embedded-1.1 or arquillian-weld-se-embedded. It’s squashed to one arquillian-weld-embedded and you can configure environments either programmatically or using configuration properties. See link: This new version is going to be used in Weld as soon as possible.

Maven Coordinates:

We would really appreciate if you can try it and let us know your experience!

Arquillian container SE 1.0.0.CR1 released!

2015-11-25   arquillian , testing   Tomas Remes

We are pleased to announce a new release of Arquillian container SE. If you are looking for a reliable way to test your application in Java SE then this is the right tool to try out!

This managed SE container launches new JVM process for each of your test archives. This standalone process with isolated classpath is also the main reason why we introduced such tool (and also the difference e.g to arquillian-weld-se-embedded).

You can manage your classpath dependencies by using ShrinkWrap resolver. Another option is to provide path to your directory containing your dependencies jars via container property. You can get ready your dependencies jars by using e.g Maven dependency plugin. Another options which you would expect as debugging, setting system properties or exporting deployment archive are also available. Test execution is managed by Arquillian JMX protocol.

Finally you can find some basic tests using Arquillian container SE in Weld SE tests or in CDI TCK. Feedback is more than welcomed and if you have any questions don’t hesitate to ask!

Maven Coordinates: