How to use TimeoutTest class of org.mockito.verification package

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.

JMockit can handle final and static. Just pay attention to how to set it up as it requires the -javaagent JVM parameter, or classpath tweaks, or extra annotations to be able to mock final and static stuffs.

Two more ways to do it (see my comment on the previous answer by @Tomasz Nurkiewicz):

The first relies on the fact that the compiler simply won't let you pass in something of the wrong type:

when(a.method(any(Class.class))).thenReturn(b);

You lose the exact typing (the Class<? extends A>) but it probably works as you need it to.

The second is a lot more involved but is arguably a better solution if you really want to be sure that the argument to method() is an A or a subclass of A:

when(a.method(Matchers.argThat(new ClassOrSubclassMatcher<A>(A.class)))).thenReturn(b);

Where ClassOrSubclassMatcher is an org.hamcrest.BaseMatcher defined as:

public class ClassOrSubclassMatcher<T> extends BaseMatcher<Class<T>> {

    private final Class<T> targetClass;

    public ClassOrSubclassMatcher(Class<T> targetClass) {
        this.targetClass = targetClass;
    }

    @SuppressWarnings("unchecked")
    public boolean matches(Object obj) {
        if (obj != null) {
            if (obj instanceof Class) {
                return targetClass.isAssignableFrom((Class<T>) obj);
            }
        }
        return false;
    }

    public void describeTo(Description desc) {
        desc.appendText("Matches a class or subclass");
    }       
}

Phew! I'd go with the first option until you really need to get finer control over what method() actually returns :-)

On my end if I build your project using the pom.xml you've showed us, with apache-poi declared after jfreechart, then as you've mentioned I get a corrupt JAR. Swapping the order of these two dependencies indeed gives me a correct JAR.

I've some previous experience with the maven-shade-plugin and when I used it I had trouble with the created JAR's META-INF directory, so I've checked that for defects.

I've tried to copy (using Total Commander) the META-INF directory somewhere on my local filesystem and what I've noticed is that there were errors while copying the files in META-INF/licences/. If I've tried to copy those somewhere individually and it worked but I couldn't copy the whole thing. My conclusion was that the JAR/ZIP archive is corrupt.

What I did was I entered that JAR in Total Commander (Ctrl+PgDown over the JAR file) and I renamed thirdpartylicenses.txt to thirdpartylicenses.txt.wtf. Doing this Total Commander offers to save this and it repackages the JAR (I've the Total7zip Total Commander packer plugin installed - if anyone tries this and it doesn't work try it with this installed).

After this. It works.

(I've also tried to repack the whole thing without renaming anything using Cygwin's unzip/zip commands, but that didn't work the new archive was still corrupt. Total Commander or the plugin I've mentioned does some magic.)

I guess the maven-shade-plugin merely creates a corrupt or invalid ZIP/JAR archive. I'm not sure why and maybe what I've described won't work for anyone else but I thought I'd mention it so maybe I could help.

---

I couldn't just leave this alone, so I've dug deeper and I think I've found the answer.

The bad JAR contains 65608 entries. The good JAR contains 65450 entries.

Guess what's the upper limit of the number of entries for a plain ZIP file? Yeah. The Wiki article speaks about a ZIP64 format which overcomes this limitation.

The good JAR has less entries because the actual dependencies change because of the position of the dependency declarations in your pom.xml. (As described by this answer.)

I've counted the entries like this.

Collections.list(new JarFile("...").entries()).size();

I was using Java 7 which seems to support the new ZIP64 format, so maybe if someone tries to count the entries in the bad JAR using Java 5 or 6 will receive an error (I'm not sure though).

I also tried to run the JAR exploded. I've unpacked the whole JAR into a directory and run the whole thing like this.

java -cp <dir/ com.mycompany.test.Start

Worked like a charm.

---

Bottom line. Don't overuse the maven-shade-plugin.

I have a project at work where I build my project like this.

• I copy my project's dependencies using the maven-dependency-plugin. Checkout the copy-dependencies goal. This copies your dependencies into target/dependency if I remember correctly.

• Using the maven-jar-plugin I add these dependencies to my final JAR's MANIFEST.MF as Class-Path entries using these options in the plugins configuration.

  <classpathPrefix>dependency/</classpathPrefix>
  <addClasspath>true</addClasspath>
  

  So I'll have Class-Path entries like dependency/<artifactId>-<version>.jar, etc.

• After this I'm using the maven-assembly-plugin to create a distribution ZIP which contains my final JAR and the whole dependency/ folder.
• When I deploy my application I can run it like java -jar final.jar.

Primarily I've opted to use this solution, because in my project I use some Bouncy Castle JARs which JARs have some extravagant this and that inside their META-INF directory. When I used the maven-shade-plugin to create my final runnable JAR all hell broke loose and I got nasty that method couldn't be found and this signature is not quite right errors.

You should be doing something like this also. This Maven shade business is too shady to be useful (pun intended).

---

Here's a blog post on the whole process that I've tried to describe just above (thanks to baba), maybe it'll help someone in the future.

In the end, this is all about wording.

When you think of "correct" in its very fundamental sense, as in correctness, then the answer is simply: no.

You see, the goal of an integration test is to ensure that your integrated system (consisting of multiple, different components) functions as expected. The purpose of an integration test is to verify that your "plumbing" of components works as expected. Therefore: you can't verify that your system works when parts of that system are mocked out.

But then, you can think "correctness" less strictly.

Example: companies selling cars have to test ECUs. Basically a piece of hardware, running a potentially huge software stack. These ECUs normally operate within cars. So when you want to integration test an ECU, you would have to put the ECU into a car for testing, right? A car that probably doesn't exist yet. The solution here: there are hardware emulators. You plug the ECU into that emulator, and the ECU "thinks" that sits inside a real car.

So: there are good arguments to claim "a true integration test can't use mocking", but at the same time, in the real world, such "mocking" happens all the time.

The real answer is therefore: it depends on context. Therefore there isn't a universal answer. Instead, this is about communication. You "simply" have to ensure that all people in your group/org have the same understanding of such terms.

The term itself can be interpreted in different ways. You (jointly!) pick that definition that best fits your needs, to then make sure all people contributing to your project share that view (or at least know about it).

You can't instantiate an abstract class directly, but you can easily instantiate an anonymous subclass, and that's pretty trivial in this case as you're not forced to define any methods:

Mockito.when(mockDAO.getDatabaseResults()).thenThrow(new ProblemException(){});

Alternatively, you can just use another mock:

Mockito.when(mockDAO.getDatabaseResults()).thenThrow(Mockito.mock(ProblemException.class));

This would make sense if the abstract class forced the definition of other methods you don't care about in your test.

You cant use when on getMethod, because getMethod is not a mock. It is still real object created by your class.

ArgumentCaptor has quite different purpose. Check section 15 here.

You could make your code more testable. Generally, classes that are creating new instances of other classes are difficult to test. Put some factory to this class for creating get/post methods, then in test mock this factory, and make it mock get/post methods.

public class YourClass {
  MethodFactory mf;

  public YourClass(MethodFactory mf) {
    this.mf = mf;
  }

  public void handleHttpClient(HttpClient httpClient) {
    httpClient.executeMethod(mf.createMethod());
    //your code here
  }
}

Then in test you can do:

HttpClient mockHttpClient = mock(HttpClient.class);
when(mockHttpClient.executeMethod(any(GetMethod.class)).thenReturn(HttpStatus.SC_OK);

MethodFactory factory = mock(MethodFactory.class);
GetMethod get = mock(GetMethod.class);
when(factory.createMethod()).thenReturn(get);
when(get.getResponseBodyAsStream()).thenReturn(new FileInputStream(source));

UPDATE

You can also try some nasty hack, and Answer and accessing GetMethod's private parts ;) by reflection. (This is really nasty hack)

when(mockHttpClient.executeMethod(any(GetMethod.class))).thenAnswer(new Answer() {
  Object answer(InvocationOnMock invocation) {
    GetMethod getMethod = (GetMethod) invocation.getArguments()[0];

    Field respStream = HttpMethodBase.class.getDeclaredField("responseStream");
    respStream.setAccessible(true);
    respStream.set(getMethod, new FileInputStream(source));

    return HttpStatus.SC_OK;
  }
});

I think this should work:

    @PrepareForTest({UtilDatabaseSoldeAutoCdeCommon.class})
    public class SomeTest {
        @Mock
        UtilDatabaseSoldeAutoCdeCommon fakeSingletonInstance;   

        @Test
        public void test() {
             Whitebox.setInternalState(UtilDatabaseSoldeAutoCdeCommon.class, "instance", fakeSingletonInstance);
             // Write here your test
        }
    }

You can set a default answer for a mock. All methods that aren't stubbed will use this default answer.

public void testUnstubbedException() {
    // Create a mock with all methods throwing a RuntimeException by default
    SomeClass someClass = mock( SomeClass .class, new RuntimeExceptionAnswer() );

    doReturn(1).when(someClass).getId(); // Must use doReturn

    int id = someClass.getId(); // Will return 1

    someClass.unstubbedMethod(); // Will throw RuntimeException
}

public static class RuntimeExceptionAnswer implements Answer<Object> {

    public Object answer( InvocationOnMock invocation ) throws Throwable {
        throw new RuntimeException ( invocation.getMethod().getName() + " is not stubbed" );
    }

}

Note that you cannot use when with this functionality, since the method is called before when (How does mockito when() invocation work?) and it will throw a RuntimeException before the mock goes into stubbing mode.

Therefore, you must use doReturn for this to work.