There is no doubt that unit/component testing is essential for most of the applications. Sometimes the component under the test needs to communicate with other components. This is where we usually reach for mocking frameworks. And if it's not sufficient (or too complicated) there are still integration tests. Integration tests are usually more time and resource-consuming though. And for CDI components mocks might very oftten become too complex. Not to mention the services provided by the container (interceptors, decorators, events, programmatic lookup, etc.) are hard to mock (if at all). That's the reason why Arquillian has an embedded Weld container. Recently, the first beta version (beta but stable and ready to use) of Weld JUnit extensions was released. Well, it's just another tool for testing CDI components. So how does it differ from other tools such as Arquillian, DeltaSpike Test Control and CDI-Unit? Well, it's really simple, easy to use, fast and it leverages the powerful Weld SE Bootstrap API.


Get Started

Just add one dependency to your pom.xml:




NOTE: At the time I wrote this article the artifact was only available in JBoss Maven repository. However, it should reach the Maven Central sooner or later.


And then add WeldInitiator test rule to your test:


import static org.junit.Assert.assertEquals;
import org.junit.Rule;
import org.junit.Test;

public class SimpleTest {

    public WeldInitiator weld = WeldInitiator.of(Foo.class);

    public void testFoo() {
        // Note that Weld container is started automatically
        // WeldInitiator can be used to perform programmatic lookup of beans
        // WeldInitiator can be used to fire a CDI event
        weld.event().select(Baz.class).fire(new Baz());



org.jboss.weld.junit.WeldInitiator is a test rule (JUnit 4.9+) which starts/stops a Weld container per test method execution. The container is configured through the Weld SE Bootstrap API, i.e. a provided instance. A convenient static method WeldInitiator.of(Class<?>...) is also provided - in this case, the container is optimized for testing purposes (with automatic discovery and concurrent deployment disabled) and only the given bean classes are considered. WeldInitiator also implements javax.enterprise.inject.Instance and therefore might be used to perform programmatic lookup of bean instances. It's also possible to use the convenient static method WeldInitiator.ofTestPackage() - the container is optimized for testing purposes and all the classes from the test class package are added. Sometimes, the programmatic lookup can imply unnecessary overhead, e.g. an annotation literal must be used for parameterized types and qualifiers with members. WeldInitiator.inject(Object) instructs the rule to inject the given non-contextual instance once the container is started, i.e. during each test method execution:


public class InjectTest {

    public WeldInitiator weld = WeldInitiator.of(Foo.class).inject(this);

    // Gets injected by WeldInitiator when testFoo() is about to be run
    Foo foo;

    public void testFoo() {
        assertEquals(42, foo.getValue());



And that's basically all. The Weld SE Bootstrap API is really powerful and allows to minimize the set of classes to be processed by the CDI container. As a result, the tests are fast and lightweight!