Search code examples
javamockitojersey-test-framework

Mockito with Jersey Test and JAX-RS - UnsatisfiedDependencyException


Trying to test a fairly simple JAX-RS endpoint

@ApplicationScoped
@Path("mypath")
public class MyRestService {
    @Inject
    private Logger logger;

    @Inject
    private EjbService ejbService;

    @GET
    public String myMethod() {
        logger.info("...");
        return ejbService.myMethod();
    }
}

with Mockito and Jersey Test

@RunWith(MockitoJUnitRunner.class)
public class MyRestServiceTest extends JerseyTest {
    @Mock
    private EjbService ejbService;

    @Mock
    private Logger logger;

    @InjectMocks
    private MyRestService myRestService;

    ...

    @Override
    protected Application configure() {
        MockitoAnnotations.initMocks(this);
        return new ResourceConfig().register(myRestService);
    }
}

The Grizzly container is returning a org.glassfish.hk2.api.UnsatisfiedDependencyException for Logger and EjbService even thought the dependencies are injected correctly by Mockito.

Seems Grizzly is trying, correctly, to ovverride the Mockito mocks. If I register an AbstractBinder in the configure method, everything works fine.

.register(new AbstractBinder() {
    @Override
    protected void configure() {
        bind(ejbService).to(EjbService.class);
        bind(logger).to(Logger.class);
    }
});

But I don't feel it's the best way to accomplish injection. Mockito style is better imho. What do I need to do to solve this issue?


Solution

  • The MockitoJUnitRunner is for unit tests and JerseyTest is for integration tests.

    When using Mockito, your tests will call directly the declared myRestService and Mockito dependency injection will take place.

    When using JerseyTest, a new web container is created and your tests talk to MyRestService via an HTTP call. Inside this container, the real dependency injection is happening, the classes are not even seeing you declared mocks.

    You can use JerseyTest and Mockito together, exactly as you did. It just requires some extra configurations (as you already found) and the @RunWith annotation is not necessary.