How to use SomeClass method of org.mockitousage.junitrunner.DeepStubbingWithJUnitRunnerTest class

This post does not directly answer your question but provides a different point of view.

One approach to make your clients consistently call close is to free them from this responsibility.

How can you do it?

Use template pattern.

Sketch implementation

You mentioned that you're working with TCP, so let's assume that you have a TcpConnection class that has a close() method.

Let's define TcpConnectionOperations interface:

public interface TcpConnectionOperations {
  <T> T doWithConnection(TcpConnectionAction<T> action);
}

and implement it:

public class TcpConnectionTemplate implements TcpConnectionOperations {
  @Override
  public <T> T doWithConnection(TcpConnectionAction<T> action) {
    try (TcpConnection tcpConnection = getConnection()) {
      return action.doWithConnection(tcpConnection);
    }
  }
}

TcpConnectionAction is just a callback, nothing fancy.

public interface TcpConnectionAction<T> {
  T doWithConnection(TcpConnection tcpConnection);
}

How the library should be consumed now?

• It must be consumed only through TcpConnectionOperations interface.
• Consumers supply actions

For example:

String s = tcpConnectionOperations.doWithConnection(connection -> {
  // do what we with with the connection
  // returning to string for example
  return connection.toString();
});

Pros

• Clients don't have to worry about:
• • getting a TcpConnection
• • closing the connection
• You are in control of creating connections:
• • you can cache them
• • log them
• • collect statistics
• • many other use cases...
• In tests you can provide mock TcpConnectionOperations and mock TcpConnections and make assertions against them

Cons

This approach may not work if the lifecycle of a resource is longer than action. E.g. it is necessary for the client to keep the resource for a longer time.

Then you might want to dive deep in ReferenceQueue/Cleaner (since Java 9) and related API.

Inspired by Spring framework

This pattern is widely used in Spring framework.

See for example:

• JdbcTemplate
• TransactionTemplate
• JmsTemplate.
• (there are many others)

Update 2/7/19

How can I cache/reuse the resource?

This is some kind of pooling:

a pool is a collection of resources that are kept ready to use, rather than acquired on use and released

Some pools in Java:

• HikariCP is a JDBC connection pool library
• OkHttps ConnectionPool
• Tomcat JDBC Connection pool
• ThreadPoolExecutor

When implementing a pool several questions are raised:

• When the resource actually should be closed?
• How the resource should be shared between multiple threads?

When the resource should be closed?

Usually pools provide an explicit close method (it may have a different name but the purpose is the same) which closes all the resources held.

• HikariDataSource#close
• ConnectionPool#evictAll "Close and remove all idle connections in the pool."
• ConnectionPool#close
• ThreadPoolExecutor#shutdown

How it can be shared across multiple threads?

It depends on a kind of the resource itself.

Usually you want to ensure that only one thread accesses one resource.

This can be done using some kind of locking

Demo

Note that code provided here is only for demonstration purposes It has awful performance and violates some OOP principles.

IpAndPort.java

@Value
public class IpAndPort {
  InetAddress address;
  int port;
}

TcpConnection.java

@Data
public class TcpConnection {
  private static final AtomicLong counter = new AtomicLong();

  private final IpAndPort ipAndPort;
  private final long instance = counter.incrementAndGet();

  public void close() {
    System.out.println("Closed " + this);
  }
}

CachingTcpConnectionTemplate.java

public class CachingTcpConnectionTemplate implements TcpConnectionOperations {
  private final Map<IpAndPort, TcpConnection> cache
      = new HashMap<>();
  private boolean closed; 
  public CachingTcpConnectionTemplate() {
    System.out.println("Created new template");
  }

  @Override
  public synchronized <T> T doWithConnectionTo(IpAndPort ipAndPort, TcpConnectionAction<T> action) {
    if (closed) {
      throw new IllegalStateException("Closed");
    }
    TcpConnection tcpConnection = cache.computeIfAbsent(ipAndPort, this::getConnection);
    try {
      System.out.println("Executing action with connection " + tcpConnection);
      return action.doWithConnection(tcpConnection);
    } finally {
      System.out.println("Returned connection " + tcpConnection);
    }
  }

  private TcpConnection getConnection(IpAndPort ipAndPort) {
    return new TcpConnection(ipAndPort);
  }


  @Override
  public synchronized void close() {
    if (closed) {
      throw new IllegalStateException("closed");
    }
    closed = true;
    for (Map.Entry<IpAndPort, TcpConnection> entry : cache.entrySet()) {
      entry.getValue().close();
    }
    System.out.println("Template closed");
  }
}

Tests infrastructure

TcpConnectionOperationsParameterResolver.java

public class TcpConnectionOperationsParameterResolver implements ParameterResolver, AfterAllCallback {
  private final CachingTcpConnectionTemplate tcpConnectionTemplate = new CachingTcpConnectionTemplate();

  @Override
  public boolean supportsParameter(ParameterContext parameterContext, ExtensionContext extensionContext) throws ParameterResolutionException {
    return parameterContext.getParameter().getType().isAssignableFrom(CachingTcpConnectionTemplate.class)
        && parameterContext.isAnnotated(ReuseTemplate.class);
  }

  @Override
  public Object resolveParameter(ParameterContext parameterContext, ExtensionContext extensionContext) throws ParameterResolutionException {
    return tcpConnectionTemplate;
  }

  @Override
  public void afterAll(ExtensionContext context) throws Exception {
    tcpConnectionTemplate.close();
  }
}

The ParameterResolver and AfterAllCallback are from JUnit.

@ReuseTemplate is a custom annotation

ReuseTemplate.java:

@Retention(RetentionPolicy.RUNTIME)
public @interface ReuseTemplate {
}

Finally test:

@ExtendWith(TcpConnectionOperationsParameterResolver.class)
public class Tests2 {
  private final TcpConnectionOperations tcpConnectionOperations;

  public Tests2(@ReuseTemplate TcpConnectionOperations tcpConnectionOperations) {
    this.tcpConnectionOperations = tcpConnectionOperations;
  }

  @Test
  void google80() throws UnknownHostException {
    tcpConnectionOperations.doWithConnectionTo(new IpAndPort(InetAddress.getByName("google.com"), 80), tcpConnection -> {
      System.out.println("Using " + tcpConnection);
      return tcpConnection.toString();
    });
  }

  @Test
  void google80_2() throws Exception {
    tcpConnectionOperations.doWithConnectionTo(new IpAndPort(InetAddress.getByName("google.com"), 80), tcpConnection -> {
      System.out.println("Using " + tcpConnection);
      return tcpConnection.toString();
    });
  }

  @Test
  void google443() throws Exception {
    tcpConnectionOperations.doWithConnectionTo(new IpAndPort(InetAddress.getByName("google.com"), 443), tcpConnection -> {
      System.out.println("Using " + tcpConnection);
      return tcpConnection.toString();
    });
  }
}

Running:

$ mvn test

Output:

Created new template
[INFO] Running Tests2
Executing action with connection TcpConnection(ipAndPort=IpAndPort(address=google.com/74.125.131.102, port=80), instance=1)
Using TcpConnection(ipAndPort=IpAndPort(address=google.com/74.125.131.102, port=80), instance=1)
Returned connection TcpConnection(ipAndPort=IpAndPort(address=google.com/74.125.131.102, port=80), instance=1)
Executing action with connection TcpConnection(ipAndPort=IpAndPort(address=google.com/74.125.131.102, port=443), instance=2)
Using TcpConnection(ipAndPort=IpAndPort(address=google.com/74.125.131.102, port=443), instance=2)
Returned connection TcpConnection(ipAndPort=IpAndPort(address=google.com/74.125.131.102, port=443), instance=2)
Executing action with connection TcpConnection(ipAndPort=IpAndPort(address=google.com/74.125.131.102, port=80), instance=1)
Using TcpConnection(ipAndPort=IpAndPort(address=google.com/74.125.131.102, port=80), instance=1)
Returned connection TcpConnection(ipAndPort=IpAndPort(address=google.com/74.125.131.102, port=80), instance=1)
Closed TcpConnection(ipAndPort=IpAndPort(address=google.com/74.125.131.102, port=80), instance=1)
Closed TcpConnection(ipAndPort=IpAndPort(address=google.com/74.125.131.102, port=443), instance=2)
Template closed

The key observation here is that connections are reused (see "instance=")

This is oversimplified example of what can be done. Sure, in the real world pooling connections is not so simple. The pool should not grow indefinitely, connections can be kept only for specific period of time and so on. Usually some problems are solved by having something in the background.

Returning to the question

I don't see how to use try-with-resources statement in the context of tests (I'm using JUnit5 with Mockito), in that the "resource" is not short-lived - it is part of the test fixture.

See Junit 5 User Guide. Extension model

Being diligent as always, I tried implementing finalize() and testing for closure there, but it turns out finalize() is not even called (Java10). This is also marked as deprecated and I'm sure this idea will be frowned upon.

You overrode finalize so that it throws an exception but they are ignored.

See Object#finalize

If an uncaught exception is thrown by the finalize method, the exception is ignored and finalization of that object terminates.

The best you can do here is to log the resource leakage and close the resource

To be clear, I want the application's tests (that use my library) to fail if they don't call close() on my objects.

How do application tests use your resource? Do they instantiate it using new operator? If yes then I think PowerMock can help you (but I'm not sure)

If you have hidden instantiation of the resource behind some kind of a factory then you can give the application tests some mock factory

---

If you're interested you can watch this talk. It's in Russian, but still may be helpful (part of my answer is based on this talk).

I'll leave this here for future reference and to be able to elaborate a bit more, even though I've answered in the comments.

What you're trying to accomplish is to put the stream in the onError flow. Unfortunately, by mocking it like this:

Mockito.`when`(apiManager.getPlacesPagedObservable(
                   Mockito.anyString(), Mockito.anyInt()))
                           .thenThrow(Exception(EXCEPTION_MESSAGE1))

You're actually telling Mockito to setup your mock in a way that just calling apiManager.getPlacesPagedObservable(anystring, anystring) should thrown an exception.

It is indeed true that throwing an exception inside an Rx stream will cause the entire stream to stop and end up in the onError method. However, this is exactly the problem with the approach you're using. You're not inside the stream when the exception is thrown.

Instead what you want to do is tell Mockito that once you call apiManager.getPlacesPagedObservable(anystring, anystring) you want to return a stream that will end up in the onError. This can be easily achieved with Observable.error() like so:

Mockito.`when`(apiManager.getPlacesPagedObservable(
               Mockito.a‌​nyString(), Mockito.anyInt()))
                    .thenReturn(Observable.error(
                                Exception(EXCEPTION_MESSAGE1)))

(It might be possible that you need to add some type information in this part here Observable.error(), you might also need to use something else instead of an observable - single, completable, etc.)

The mocking above will tell Mockito to setup your mock to return an observable that will error as soon as it's subscribed to. This will in turn put your subscriber directly in the onError stream with the specified exception.

This should work

import static org.mockito.ArgumentMatchers.any;
import static org.mockito.Mockito.verify;

verify(bar).DoStuff(any(Foo[].class));

Several of the methods on AbstractHttpClient are final and thus won't be mocked. IMO, this behavior is the #1 reason not to mock concrete classes.

I have finally found the solution for this problem.

We have used an anonymous class extending original Sbb class which was tested and in this extended class implementation of mentioned method was altered and throws expression was removed which caused the problem.

I should have read my colleagues code more carefully.

This comes down to the implementation of the spy. According to the docs, the Spy is created as a copy of the real instance:

Mockito does not delegate calls to the passed real instance, instead it actually creates a copy of it. So if you keep the real instance and interact with it, don't expect the spied to be aware of those interaction and their effect on real instance state. The corollary is that when an unstubbed method is called on the spy but not on the real instance, you won't see any effects on the real instance.

It seems to be a shallow copy. As a result, as far as my debugging shows, the CacheLoader is shared between the copy and the original object, but its reference to its enclosing object is the original object, not the spy. Therefore the real retrieveValue is called instead of the mocked one.

I'm not sure offhand what the best way to resolve this would be. One way for this specific example would be to invert the CacheLoader dependency (i.e. pass it into Subject instead of Subject defining it internally), and mock that instead of Subject.

Only mock the things which you cannot create or pass through yourself. Do not mock any passed-in entities; providing a fake version is often far superior.

In this scenario, we can get away with a couple of things since we know a few things about our test:

• We are getting back a Customer instance from the customerService, but we don't need to do any sort of validation on that instance.
• We have to mock the customerService out since it is an injected dependency.

In light of these two things, we should mock out CustomerService, which you do kind of successfully - since the field is named the same you don't need the extra metadata in the annotation.

@Mock
private CustomerService customerService;

You should also look to use the test runner provided with Mockito so you don't have to explicitly initialize the mocks.

@RunWith(MockitoJUnitRunner.class)
public class RestaurantTest {
    // tests
}

Now, on to the actual unit test. The only thing that really sucks is that you have to provide an instance of a Customer to use, but outside of that, it's not too bad. Our givens are the instance of CustomerData we want to mutate, and the Customer we're providing for test. We then have to simply assert the values that we care about are coming back for our test CustomerData instance.

@Test
public void updateCustomer_WithValidInput_ShouldReturnUpdatedInput(){
    //given
    final Customer customer = new Customer();
    customer.setId("123");
    customer.setAddress("Addr1");
    customer.setName("Bob");
    customer.setCity("St8")
    customer.setLanguage("Java");

    final CustomerInputData inputData = new CustomerInputData();
    inputData.setId(customer.getId());

    //when
    when(customerService.getCustomerById(customer.getId())).thenReturn(customer);
    classUnderTest.updateCustomer(customerData);

    //then
    verify(customerService.getCustomerById("123"));
    assertThat(customerData.getCustomerName(), equalTo(customer.getName()))
    // and so forth
}

Use statement like this before mocked object compareTo() method calling:

when(mockedObject.compareTo(any(Sortable.class))).thenCallRealMethod();

Mockito has some powerful tools for this.

List<MyClass> list = new ArrayList<>();
when(mapper.query(eq(MyClass.class), any(DynamoDBQueryExpression.class)))
    .thenReturn(mock(PaginatedQueryList.class, withSettings().defaultAnswer(new ForwardsInvocations(list))));

This will return a mocked PaginatedQueryList which forwards all method calls to list.