How to use mockClassStatic method of org.mockito.internal.creation.bytebuddy.BytecodeGenerator class

Dependency Injection

If you inject the Bar instance, or a factory that is used for creating the Bar instance (or one of the other 483 ways of doing this), you'd have the access necessary to do perform the test.

Factory Example:

Given a Foo class written like this:

public class Foo {
  private BarFactory barFactory;

  public Foo(BarFactory factory) {
    this.barFactory = factory;
  }

  public void foo() {
    Bar bar = this.barFactory.createBar();
    bar.someMethod();
  }
}

in your test method you can inject a BarFactory like this:

@Test
public void testDoFoo() {
  Bar bar = mock(Bar.class);
  BarFactory myFactory = new BarFactory() {
    public Bar createBar() { return bar;}
  };
  
  Foo foo = new Foo(myFactory);
  foo.foo();

  verify(bar, times(1)).someMethod();
}

Bonus: This is an example of how TDD(Test Driven Development) can drive the design of your code.

Well mockito mocks works by extending the class and overriding the method, which in your case is not possible on A.a(String). If you want this to happen you have to remove the final modifier.

Now assuming A.a(String) is not final, what you ask is completely doable with mockito:

given(mockA.a(anyString()).willAnswer(returnOfB(bInstance));

Answer<String> returnOfB(final B bInstance) {
    return new Answer<String>() {
         public String answer(Invocation invocation) {
             String arg = (String) invocation.getActualArguments()[0];
             return bInstance.b(arg);
         }
    };
}

Please note this answer has been written on a phone and might have typo, or wrong names, though you should get the idea of what should be done to achieve what you want.

Cheers

You can use MockingDetails and either printInvocations or getInvocations to inspect the interactions belonging to a mock. However, this will not produce a list of invocations belonging to multiple mocks in the order that happened: just interactions with each individual mock.

Code snippet, as contributed by elhefe and Anand Rockzz:

import static org.mockito.Mockito.mockingDetails;

System.out.println(mockingDetails(mock).printInvocations());
/* or */
System.out.println(mockingDetails(mock).getInvocations());

Acknowledging your reluctance and caveats in the comments, I would say that this is a technique that does more to lock in your current implementation than to analyze your real constraints and prevent regressions. Furthermore, if your algorithm has a lot of interactions with direct collaborators, that might be an indication that the algorithm should be refactored.

If the system is untested or undocumented legacy code, this might be a practical way to programmatically generate a regression test or analysis--a temporary starting point for more-informed regression testing--but in your shoes I would instead start by documenting the contract of each component and then writing a test that confirms those interactions and constraints. Mockito recommendations (as intimated through this article by Mockito's original developer) tend toward adding stubs until tests pass and adding verifications/counts only where there are expensive or non-idempotent side effects.

Use ResourceBundle.getBundle( String, ResourceBundle.Control ) to get ResourceBundle to cache a bundle for the given String. You can subclass ResourceBundle.Control to provide any type of bundle your heart desires.

@Test
public void myTest()
{
    // In your Test's init phase run an initial "getBundle()" call
    // with your control.  This will cause ResourceBundle to cache the result.
    ResourceBundle rb1 = ResourceBundle.getBundle( "blah", myControl );

    // And now calls without the supplied Control will still return
    // your mocked bundle.  Yay!
    ResourceBundle rb2 = ResourceBundle.getBundle( "blah" );
}

Here's the subclassed Control:

ResourceBundle.Control myControl = new ResourceBundle.Control()
{
    public ResourceBundle newBundle( String baseName, Locale locale, String format,
            ClassLoader loader, boolean reload )
    {
        return myBundle;
    }
};

And here's one way to mock the ResourceBundle (filling up the TreeMap with keys/values as needed for the unit tests left as an exercise for the reader):

ResourceBundle myBundle = new ResourceBundle()
{
    protected void setParent( ResourceBundle parent )
    {
      // overwritten to do nothing, otherwise ResourceBundle.getBundle(String)
      //  gets into an infinite loop!
    }

    TreeMap<String, String> tm = new TreeMap<String, String>();

    @Override
    protected Object handleGetObject( String key )
    {
        return tm.get( key );
    }

    @Override
    public Enumeration<String> getKeys()
    {
        return Collections.enumeration( tm.keySet() );
    }
};

You need to create a MOCK of pcUserService first, and then use that mock.

PcUserService mock = org.mockito.Mockito.mock(PcUserService.class);
when(mock.read("1")).thenReturn(pcUser);

Lenient mocks are what you want, if you can't just use a real UserKeychain.

Mockito.lenient().when(userKeychain.getUserStatus()).thenReturn(UserState.OK);
Mockito.lenient().when(otherUserKeychain.getUserStatus()).thenReturn(UserState.SUSPENDED);

Mockito is designed to replace systems where you can't use the real system in your test, particularly in systems that predictably invoke services instead of getting properties from data objects (or other idempotent actions). Because your system doesn't call those methods in a deterministic order, and because the calls aren't expensive and don't have side effects, I would recommend just going with the "lenient" option.

Imagine this case instead, where you are testing deleting user 1001:

when(userRpc.deleteUser(1001)).thenReturn(RPC_SUCCESS);
when(userRpc.deleteUser(1002)).thenReturn(RPC_SUCCESS);  // unnecessary

The test might pass if you ever delete the wrong user: Over-stubbing has masked a problem. Compare with this:

when(userRpc.fetchExpensiveUserDetails(1001)).thenReturn(user1001);
when(userRpc.fetchExpensiveUserDetails(1002)).thenReturn(user1002);  // unnecessary

Depending on what you're testing, this might be dangerous, but might not be so bad. Simulating a slow mobile network or with expensive data, maybe it is entirely against spec for you to fetch too much. However, in other cases, it may be acceptable. Finally, compare this case:

when(calculationResult.getRealComponent()).thenReturn(-1d);
when(calculationResult.getComplexComponent()).thenReturn(5);
when(calculationResult.getShortString()).thenReturn("-1 + 5i");

calculationResult looks an awful lot like a data object, and it is probably not a critical part of your test which of your methods to call or whether you're calling all of them. This is a case where Mockito's strict stubbing hinders you rather than helping you, and might be a case where you want to make some of those stubbings lenient. You might also choose to make the entire mock lenient, which particularly makes sense if you were to create a test helper method like stubCalculationResult(-1, 5) that prepared an entire object for you like that.

The only option better than that is to use a real object. In my example, if CalculationResult is an existing well-defined object, it may be lower risk overall to use a real one than to mock the behavior you believe at test-writing time to be correct. Similarly for your case, if you have access to a UserKeychain constructor that populates UserStatus etc, then it may be safer to use that in a test.

Though this might appear at first glance to be a slippery slope into turning a unit test into an integration test, I'd like to clarify that I'm recommending this only for data objects, which have no dependencies, and which ideally are immutable objects that have no methods with side-effects. If you use dependency injection, these are the type of single-implementation data holders that you would call new on rather than getting from your graph. This is also a good reason to separate your data objects so they are immutable and easy to construct, and to shift your services to consume those objects rather than giving methods to the data objects (favoring loginService.login(user) rather than user.login(loginService)).

As you noted, these kind of tests are pointless (unless you're writing a unit test for Mockito itself, of course :-)).

The point of mocking is to eliminate external dependencies so you can unit-test your code without depending on other classes' code. For example, let's assume you have a class that uses the Employee class you described:

public class EmployeeExaminer {
    public boolean isJim(Employee e, int i) {
        return "Jim".equals(e.getName(i));
    }
}

And you'd like to write a unit test for it. Of course, you could use the actual Employee class, but then your test won't be a unit-test any more - it would depend on Employee's implementation. Here's where mocking comes in handy - it allows you to replace Employee with a predictable behavior so you could write a stable unit test:

// The object under test
EmployeeExaminer ee = new EmployeeExaminer();

// A mock Employee used for tests:
Employee emp = mock(Employee.class);
when(emp.getName(1)).thenReturn("Jim");
when(emp.getName(2)).thenReturn("Mark");

// Assert EmployeeExaminer's behavior:
assertTrue(ee.isJim(emp, 1));
assertFalse(ee.isJim(emp, 2));

You can enable verbose logging on your Mocked objects:

    import org.mockito.Mockito.mock;
    import org.mockito.Mockito.withSettings;

    List mockWithLogger = mock(List.class, withSettings().verboseLogging());

This should give you more information to understand the interactions.

https://javadoc.io/doc/org.mockito/mockito-core/latest/org/mockito/MockSettings.html#verboseLogging()

Consider having your @Test method simply declare the exceptions being thrown, or even declaring throws Exception.

@Test
public void testFoo() throws Exception {
  // mocking and test code here
}