how properly mock UriInfo?

Question

That's my piece of code:

import java.net.URI;
import javax.ws.rs.core.UriInfo;
(...)

    UriInfo mockUriInfo;
    String url = "test";

    mockUriInfo = mock(UriInfo.class);
    when(mockUriInfo.getRequestUri()).then(new URI(url));

Unfortunately I've got an error:

then(org.mockito.stubbing.Answer) cannot be applied to (java.new URI)

Any idea how can i resolve it?

Yosef-at-Panaya · Accepted Answer · 2015-04-21T13:44:25.007

2

you need to use thenReturn and not then:

when(mockUriInfo.getRequestUri()).thenReturn(new URI(url));

if you want to use then (that is a synonym of thenAnswer you need to pass an answer as parameter :

when(mockUriInfo.getRequestUri()).then(new Answer<Integer>() {
    public URI answer(InvocationOnMock invocation) throws Throwable {
        return new URI(url);
    }
}

edited Apr 21 '15 at 13:44

answered Apr 21 '15 at 13:39

Yosef-at-Panaya

676
4
13

score 0 · Answer 2 · edited May 23 '17 at 10:30

0

Don't mock types you don't own

Really it's wrong 99% of the time. Instead it will be better to use real objects or use integration tests (with RESTAssured, or something else).

On the mockito wiki : Don't mock types you don't own !

This is not a hard line, but crossing this line may have repercussions! (it most likely will.)

Imagine code that mocks a third party lib. After a particular upgrade of a third library, the logic might change a bit, but the test suite will execute just fine, because it's mocked. So later on, thinking everything is good to go, the build-wall is green after all, the software is deployed and... Boom

It may be a sign that the current design is not decoupled enough from this third party library.

Also another issue is that the third party lib might be complex and require a lot of mocks to even work properly. That leads to overly specified tests and complex fixtures, which in itself compromises the compact and readable goal. Or to tests which do not cover the code enough, because of the complexity to mock the external system.

Instead, the most common way is to create wrappers around the external lib/system, though one should be aware of the risk of abstraction leakage, where too much low level API, concepts or exceptions, goes beyond the boundary of the wrapper. In order to verify integration with the third party library, write integration tests, and make them as compact and readable as possible as well.

edited May 23 '17 at 10:30

Community

1
1

answered Apr 21 '15 at 14:28

bric3

40,072
9
91
111

1

Advice is fine, but if you don't actually answer the question, that gets a downvote. – Tim Keating Oct 04 '17 at 21:31
@TimKeating I’m suggesting another approach. One is to use the real object in this case, I suppose the reader will know how to look for the concrete implementation. Every answer don’t have to contain _copy/paste-able_ code to answer the question. – bric3 Oct 05 '17 at 06:47
The "real object" is an Interface. And the implementation doesn't seem to exist. I have looked all over the internet for it. – sbzoom Apr 03 '18 at 03:23
@sbzoom "real object" means **not mocks**. In other words objects that are created via standard APIs be it a constructor or a builder, or a factory. – bric3 Apr 03 '18 at 07:03
@sbzoom Also not **all over the internet**, look at [jersey](https://github.com/jersey/jersey/blob/2.26/core-server/src/main/java/org/glassfish/jersey/server/ExtendedUriInfo.java) or [CXF](https://github.com/apache/cxf/blob/cxf-3.2.4/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/impl/UriInfoImpl.java) or [RestEasy](https://github.com/resteasy/Resteasy/blob/3.5.0.Final/resteasy-jaxrs/src/main/java/org/jboss/resteasy/spi/ResteasyUriInfo.java). Plus since JAX-RS is a specficiation, it is very likely the implementation exists on the classpath of the project for this application to work. – bric3 Apr 03 '18 at 07:05

how properly mock UriInfo?

2 Answers2

Don't mock types you don't own