How to use StackTraceBuilder class of org.mockito.exceptions.base package

Try Mockito and you will love it!

You can have a look of this library in this blog post, showing 6 simple examples of Mockito usage.

A short example:

@Test
public void iteratorWillReturnHelloWorld(){
    //arrange
    Iterator i = mock(Iterator.class);
    when(i.next()).thenReturn("Hello").thenReturn("World");
    //act
    String result = i.next() + " " + i.next();
    //assert
    assertEquals("Hello World", result);
}

Edit regarding your requirements:

It seems that Mockito runs quite well on Java 1.4 and JUnit 3, as stated in this blog post.

The same example as above, but for Java 1.4:

public void testIteratorWillReturnHelloWorld(){
    //arrange
    Iterator i = Mockito.mock(Iterator.class);
    Mockito.when(i.next()).thenReturn("Hello").thenReturn("World");
    //act
    String result = i.next() + " " + i.next();
    //assert
    assertEquals("Hello World", result);
}

If you follow the source code of jUnit. You will see that assertEquals eventually calls the equals method on the objects provided in the the isEquals method.

private static boolean isEquals(Object expected, Object actual) {
    return expected.equals(actual);
}

Source Code: https://github.com/junit-team/junit/blob/master/src/main/java/org/junit/Assert.java

This will call the .equals() method on the implementation of List. Here is the source code for the .equals() implementation of `ArrayList'.

ArrayList.equals()

  public boolean equals(Object o) {
      if (o == this) //Equality check
          return true;
      if (!(o instanceof List))  //Type check
          return false;
      ListIterator<E> e1 = listIterator();
      ListIterator e2 = ((List) o).listIterator();
      while(e1.hasNext() && e2.hasNext()) {
          E o1 = e1.next();
          Object o2 = e2.next();
          if (!(o1==null ? o2==null : o1.equals(o2))) //equality check of list contents
              return false;
      }
      return !(e1.hasNext() || e2.hasNext());
  }

You should also mock the next() method to have it return true the first time it's called, as mockito will return false by default.

Mockito.when(resultSetMock.next()).thenReturn(true).thenReturn(false);

You can do that:

doThrow(...).doNothing().when(mock).voidMethod();

(edit: use doNothing, as mentioned by @Rogério)

Your test is on methods, but it tests the whole class behavior. If your inner class is private then its an implementation detail. Something that the test shouldn't know. It there's a lot of behaviour in that inner-class and you want to test it independently maybe you should make it public and separate from this class.

Maybe you think: but then... it's a lot of code to test (a very big indivisible thing), can't I test something smaller? Well... yes. Test Driven Development mandates to make a minimal implementation and add more code only if you add more tests. So you start with some test and minimal implementation and evolve both of them until the tests have all the specification and the code all the implementation.

So don't worry about private inner classes. Test your class contract!

If auditing is truly an internal function of the class then the code should be tested as part of the unit test. Why does your class handle both complex operations and auditing? Could the auditing be moved to a separate class?

If so, introduce the auditing as a collaborator with this class and mock it out. If not, unit test it.

You can use partial mocks, but in this case I think it is an indication the class is doing too much.

With mockito 2.x, JDK 8 default methods are supported.

With mockito 1.x it's not possible,

Old answer

Unfortunately it's not yet possible (mockito 1.10.19), from the README.md on the github'page

JDK8 status

Mockito should work fine with JDK8 if you stay away from default methods (aka defender methods). Lambda usage may work just as good for Answers. We're unsure about every JDK8 features at the moment, like serializing a mock that uses a lambda. Error report and pull request are welcome though (contributing guide).

EDIT 1: defender methods and default methods are different names for the same thing.

I hope for a mockmaker replacement that will handle java 8 opcodes properly for such cases as some opcodes have a different semantic in Java 8.

EDIT 2: Updated the mockito readme, and this quote accordingly

The idea of mocking is that you totally isolate the thing that you are testing. Then, when the test fails you can be sure where the problem is without having to hunt through the whole class dependency tree. If you are testing the behaviour of multiple classes together then this is not really unit testing.

An object factory for the tests would presumably make objects with stubbed methods, and the mocking frameworks are essentially generic object factories for use in tests. But mocks provide a lot more than stubs do - a difference which Martin Fowler goes into detail on here: http://martinfowler.com/articles/mocksArentStubs.html.

If you find mocking arduous, and you also find that you are doing a lot of it, then that is a classic example of TDD telling you that your design could be improved.

Mockito can handle chained stubs:

Foo mock = mock(Foo.class, RETURNS_DEEP_STUBS);

// note that we're stubbing a chain of methods here: getBar().getName()
when(mock.getBar().getName()).thenReturn("deep");

// note that we're chaining method calls: getBar().getName()
assertEquals("deep", mock.getBar().getName());

AFAIK, the first method in the chain returns a mock, which is set up to return your value on the second chained method call.

Mockito's authors note that this should only be used for legacy code. A better thing to do otherwise is to push the behavior into your CacheContext and provide any information it needs to do the job itself. The amount of information you're pulling from CacheContext suggests that your class has feature envy.