How to use Interface MethodRule class of org.junit.rules package

You should only test the public interface of classes, not private members or private inner classes. Private members are meant to be implementation details, used only by public methods of the class (directly or indirectly). So you can unit test these indirectly via their caller methods. If you feel you don't have enough granularity in those unit tests, or that you can't sense (some of) the results you are interested in, this probably signs a problem with your design: the class may be too big, trying to do too much, thus some of its functionality may need to be extracted into a separate class, where it can then be unit tested directly.

In the current example, if the inner class itself contains a lot of code, you may simply turn it into a top-level class, then you can unit test its methods directly.

(Btw your inner class should be static if it doesn't need to refer to the enclosing class instance.)

import org.junit.Assert.*;

should be

import static org.junit.Assert.*;

Just move out the tests that don't need the setup code into a separate test class. If you have some other code common to the tests that would be helpful to keep, move that out into a helper class.

Just how you've done it. assertTrue(boolean) also has an overload assertTrue(String, boolean) where the String is the message in case of failure; you can use that if you want to print that such-and-such wasn't greater than so-and-so.

You could also add hamcrest-all as a dependency to use matchers. See https://code.google.com/p/hamcrest/wiki/Tutorial:

import static org.hamcrest.MatcherAssert.assertThat;
import static org.hamcrest.Matchers.*;

assertThat("timestamp",
           Long.parseLong(previousTokenValues[1]),
           greaterThan(Long.parseLong(currentTokenValues[1])));

That gives an error like:

java.lang.AssertionError: timestamp
Expected: a value greater than <456L>
     but: <123L> was less than <456L>

JUnit and TestNG are the main unit test frameworks.

Comparison can be found here - http://www.mkyong.com/unittest/junit-4-vs-testng-comparison

I've used JUnit in most places I've worked, it seems to be the standard, but there are some nice things in TestNG.

I've used the following in combination with JUnit to facilitate testing:

• Mockito for mocking objects - http://code.google.com/p/mockito/
• Hamcrest assertions for more readable assertions - http://code.google.com/p/hamcrest/
• Twip for parameterized testing, the JUnit stuff isn't the greatest, in fact TestNG does this better as well - http://twip.sourceforge.net/

You should use RuntimeException or subclass it. Your method has to declare checked exception (example: findByState(String state) throws IOException;) otherwise use RuntimeException:

 when(userRepository.findByState("Karnataka"))
       .thenThrow(new RuntimeException("Exception"));

According to the Mockito documentation you can set different behavior for consecutive method calls.

when(mock.someMethod("some arg"))
    .thenThrow(new RuntimeException())
    .thenReturn("foo");

In case of a void method you can do something similar (Mockito documentation)

doThrow(new RuntimeException())
    .doNothing()
    .when(mock).doSomething();

The distinction becomes clear when you have more than one test method in a class.

A @ClassRule has its before() method run before any of the test methods. Then all the test methods are run, and finally the rule's after() method. So if you have five test methods in a class, before() and after() will still only get run once each.

@ClassRule applies to a static method, and so has all the limitations inherent in that.

A @Rule causes tests to be run via the rule's apply() method, which can do things before and after the target method is run. If you have five test methods, the rule's apply() is called five times, as a wrapper around each method.

Use @ClassRule to set up something that can be reused by all the test methods, if you can achieve that in a static method.

Use @Rule to set up something that needs to be created a new, or reset, for each test method.

When you are invoking

Mockito.when(spy.isCertainValue()).thenReturn(true);

the method isCertainValue() is getting called here. This is how Java works: to evaluate the argument of Mockito.when, the result of spy.isCertainValue() must be evaluated so the method must be called.

If you don't want that to happen, you can use the following construct:

Mockito.doReturn(true).when(spy).isCertainValue();

This will have the same mocking effect but the method won't be called with this.