How to use sleep method of org.mockito.internal.verification.DummyVerificationMode class

New Answer
(October 2012)

There's no need to manually build the classpath list. Java supports a convenient wildcard syntax for directories containing jar files.

java -cp "$LIB/*"

(Notice that the * is inside the quotes.)

Explanation from man java:

As a special convenience, a class path element containing a basename of * is considered equivalent to specifying a list of all the files in the directory with the extension .jar or .JAR (a java program cannot tell the difference between the two invocations).

For example, if directory foo contains a.jar and b.JAR, then the class path element foo/* is expanded to a A.jar:b.JAR, except that the order of jar files is unspecified. All jar files in the specified directory, even hidden ones, are included in the list. A classpath entry consisting simply of * expands to a list of all the jar files in the current directory. The CLASSPATH environment variable, where defined, will be similarly expanded. Any classpath wildcard expansion occurs before the Java virtual machine is started — no Java program will ever see unexpanded wildcards except by querying the environment.

Old Answer

Good

Simple but not perfect solution:

CLASSPATH=$(echo "$LIB"/*.jar | tr ' ' ':')

There's a slight flaw in that this will not handle file names with spaces correctly. If that matters try this slightly more complicated version:

Better

CLASSPATH=$(find "$LIB" -name '*.jar' -printf '%p:' | sed 's/:$//')

This only works if your find command supports -printf (as GNU find does).

If you don't have GNU find, as on Mac OS X, you can use xargs instead:

CLASSPATH=$(find "." -name '*.jar' | xargs echo | tr ' ' ':')

Best?

Another (weirder) way to do it is to change the field separator variable $IFS. This is very strange-looking but will behave well with all file names and uses only shell built-ins.

CLASSPATH=$(JARS=("$LIB"/*.jar); IFS=:; echo "${JARS[*]}")

Explanation:

1. JARS is set to an array of file names.
2. IFS is changed to :.
3. The array is echoed, and $IFS is used as the separator between array entries. Meaning the file names are printed with colons between them.

All of this is done in a sub-shell so the change to $IFS isn't permanent (which would be baaaad).

Fail the test if an exception is caught.

@Test
public void testGetBalanceForPerson() {

   // creating mock person
   Person person1 = mock(Person.class);
   when(person1.getId()).thenReturn("mockedId");

   // calling method under test
   try {
      myClass.getBalanceForPerson(person1);
   } catch(Exception e) {
      fail("Should not have thrown any exception");
   }
}

From an identical issue that I just ran into, I suspect that sample is a mock, and you stubbed sample.getId() elsewhere? That caused this problem in my case, anyhow.

For some reason, Mockito gets upset if one of the arguments you pass to the stub used with doThrow in this way is the result of a method you also mocked. Perhaps it's a re-entrancy check of sorts to avoid infinite loops, I don't know.

Regardless, try replacing sample.getId() with a constant value and that should solve the issue. You could consider using a constant declared in your test for both the mock and any further uses of it. You could then also check that sample.getId() was used by the method you're testing by adding another call to verify.

you can mock redisTemplate like this:

@Mock
RedisTemplate<String, String> redisTemplate;

@Mock
private ValueOperations valueOperations;

@Before
public void setUp() {
    MockitoAnnotations.initMocks(this);
    Mockito.when(redisTemplate.opsForValue()).thenReturn(valueOperations);
    Mockito.doNothing().when(valueOperations).set(anyString(), anyString());
}

The error message you are getting is expected since you are using argument matcher for only one argument and not the other. From Matchers Javadoc:

If you are using argument matchers, all arguments have to be provided by matchers.

Therefore, the fix is to use a matcher for the second parameter of the method as well. In this case, it would be a matcher matching null. Depending on the version of Mockito and Java, you can have:

• Starting with Mockito 2, you can use ArgumentMatchers.isNull(). This works with Java 8 and above:

  verify(objectDemo, times(1)).objectDemoMethod(any(String.class), isNull());
  

  Note that if you're running with Java 7 or older, you'll need an explicit cast to make this work, because the type inference in those versions of Java does not take into account the types of the method called:

  verify(objectDemo, times(1)).objectDemoMethod(any(String.class), (String) isNull());
  

• If you're using Mockito 1, you can use the Matchers.isNull(clazz) instead:

  verify(objectDemo, times(1)).objectDemoMethod(any(String.class), isNull(String.class));
  

For the Java ≤ 7 or Mockito 1 cases, the examples uses a case where the second parameter was of type String: it would need to be replaced with the actual type of the method parameter.

if you do a employee = new Employee(param1, param2); you may as well skip @InjectMocks.

It is supposed to do the following:

@InjectMocks
ClassUnderTest cut;

@Mock
Dependency1 dep1;
@Mock
Dependency2 dep2;

@Before
public void setup() {
  initMocks(this);
}

omitting @InjectMocks the same behaviour can be achieved with the following code:

ClassUnderTest cut;

@Mock
Dependency1 dep1;
@Mock
Dependency2 dep2;

@Before
public void setup() {
  initMocks(this);
  cut = new ClassUnderTest(dep1, dep2);
}

In your specific case, you should mock param1 and param2. Never call the constructor manually when using @InjectMocks.

You shouldn't do that. You don't write unit tests to verify implementation details.

Your tests make sure that your public methods fulfill their contract. So you assert that things returned are as expected; or that subsequent calls to other methods give the desired output. Or you expect calls to throw specified exceptions. Or, third option: you injected mocked objects; which you later on verify that the mocks saw the method calls you specified upfront.

But writing test cases to specifically test private methods is really bad practice!

The closest thing is the Clock object. You can create a Clock object using any time you want (or from the System current time). All date.time objects have overloaded now methods that take a clock object instead for the current time. So you can use dependency injection to inject a Clock with a specific time:

public class MyBean {
    private Clock clock;  // dependency inject
    ...
    public void process(LocalDate eventDate) {
      if (eventDate.isBefore(LocalDate.now(clock)) {
        ...
      }
    }
  }

See Clock JavaDoc for more details

I think the answer is no -- perhaps you could pull it off with some intense reflection wrangling, but if so I don't think it would be worth your time.

But I think (without seeing your method), you can probably still get full coverage on your method:

• If your method takes any action after catching the exception, assert or verify that those actions happened.
  
  
• If no action happens after catching the exception, assert or verify that whatever actions were supposed to happen but were cut off by the exception, didn't happen.
  
  
• Finally, (again, not seeing your method I don't know exactly what you're dealing with) if your method is void, and nothing happens after catching the exception, and the last line of logic is what can throw the exception, then consider making your method return a boolean, have it return false if the exception is caught and true otherwise. Then in your test, make a scenario that should cause the exception to be thrown and caught, and test that the method returns false.