How to use shouldAllowCapturingArguments method of org.mockitousage.bugs.CovariantOverrideTest class

For Java 8 and above, it's easy:

when(mock.process(Matchers.anyList()));

For Java 7 and below, the compiler needs a bit of help. Use anyListOf(Class<T> clazz):

when(mock.process(Matchers.anyListOf(Bar.class)));

Take a look at this reference in the official API. You want to reverse the way your call is made and adjust the argument too, since this is a void method that you expect to throw an exception.

doThrow(new ContentIOException()).when(StubbedObject).putContent(contentStream);

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.

I solved in this way:

@Spy Response response;

...

// for assignments in code under testing:
doReturn( response ).when( dwConnector ).getResource( anyString() );

// for entity and response status reading:
doReturn( "{a:1}".getBytes() ).when( response ).readEntity( byte[].class );
doReturn( 200 ).when( response ).getStatus();

Mockito itself doesn't seem to be able to mock native methods according to this Google Group thread. However you do have two options:

1. Wrap the TableElement class in an interface and mock that interface to properly test that your SUT calls the wrapped insertRow(...) method. The drawback is the extra interface that you need to add (when GWT project should've done this in their own API) and the overhead to use it. The code for the interface and the concrete implementation would look like this:

   // the mockable interface
   public interface ITableElementWrapper {
       public void insertRow(int index);
   }
   
   // the concrete implementation that you'll be using
   public class TableElementWrapper implements ITableElementWrapper {
       TableElement wrapped;
   
       public TableElementWrapper(TableElement te) {
           this.wrapped = te;
       }
   
       public void insertRow(int index) {
           wrapped.insertRow(index);
       }
   }
   
   // the factory that your SUT should be injected with and be 
   // using to wrap the table element with
   public interface IGwtWrapperFactory {
       public ITableElementWrapper wrap(TableElement te);
   }
   
   public class GwtWrapperFactory implements IGwtWrapperFactory {
       public ITableElementWrapper wrap(TableElement te) {
           return new TableElementWrapper(te);
       }
   }
   

2. Use Powermock and it's Mockito API extension called PowerMockito to mock the native method. The drawback is that you have another dependency to load into your test project (I'm aware this may be a problem with some organizations where a 3rd party library has to be audited first in order to be used).

Personally I'd go with option 2, as GWT project is not likely to wrap their own classes in interfaces (and it is more likely they have more native methods that needs to be mocked) and doing it for yourself to only wrap a native method call is just waste of your time.

You need to do this.

when(userRepository.save(Mockito.any(User.class)))
                .thenAnswer(i -> i.getArguments()[0]);

And now you can obtain user which you pass as argument.

Most important concept in the Gradle java-test-fixtures plugin is stated in their documentation:

[this plugin] will automatically create a testFixtures source set, in which you can write your test fixtures. Test fixtures are configured so that:

• they can see the main source set classes
• test sources can see the test fixtures classes

This plugin will indeed create the following dependencies: main <-- testFixtures , and testFixtures <-- test

In your case, testFixtures module should automatically depend on main sources, and also on main dependencies declared in api scope ( com.my.extenal.project:1.0)

See a similar example in a valid sample project here https://github.com/mricciuti/so-64133013 :

• Simpsons class has access to Person class from main module
• TestHelpers class has access to main dependencies declared in api configuration

Note that testFixtures will not inherit dependencies from the test module: if you need to use such libraries in this module (eg. JUnit, Mockito, ...) you will need to declare explicit dependency , using testFixturesImplementation or testFixturesApi configuration.

See example in core-module

plugins {
    id ("java-library")
    id ("java-test-fixtures")
}
dependencies {
    // Main dependencies
    //   will be available in "testFixture" as well thanks to "api" configuration
    api("org.apache.commons:commons-lang3:3.9")
    api(project(":utils-module"))

    // Testfixture dependencies
        // ==> mockito lib will be available in testFixture module and also in consumer modules (e.g test)
    testFixturesApi("org.mockito:mockito-core:3.5.13")

    // Test dependencies
       // dependencies specific to the "test" module; not visible from "testFixtures"
    testImplementation("org.junit.jupiter:junit-jupiter-api:5.3.1")
    testRuntimeOnly ("org.junit.jupiter:junit-jupiter-engine:5.3.1")
}

@Mock creates a mock. @InjectMocks creates an instance of the class and injects the mocks that are created with the @Mock (or @Spy) annotations into this instance.

Note you must use @RunWith(MockitoJUnitRunner.class) or Mockito.initMocks(this) to initialize these mocks and inject them (JUnit 4).

With JUnit 5, you must use @ExtendWith(MockitoExtension.class).

@RunWith(MockitoJUnitRunner.class) // JUnit 4
// @ExtendWith(MockitoExtension.class) for JUnit 5
public class SomeManagerTest {

    @InjectMocks
    private SomeManager someManager;

    @Mock
    private SomeDependency someDependency; // this will be injected into someManager
 
     // tests...

}

If you're able to refactor your code, you can wrap your calls to the final/static methods in simple instance methods, for example:

protected Foo doBar(String name) {
    return Utility.doBar(name);
}

This allows you to override your wrapper method in the unit test to return a mock instance of Foo.

Alternatively you can use Powermock, which extends Easymock (and Mockito) to allow mocking of final and static methods:

PowerMock is a framework that extend other mock libraries such as EasyMock with more powerful capabilities. PowerMock uses a custom classloader and bytecode manipulation to enable mocking of static methods, constructors, final classes and methods, private methods, removal of static initializers and more.

Here's an example test mocking a static final method, the example shows how to mock some other types too:

@Test
public void testMockStaticFinal() throws Exception {
    mockStatic(StaticService.class);
    String expected = "Hello altered World";
    expect(StaticService.sayFinal("hello")).andReturn("Hello altered World");
    replay(StaticService.class);

    String actual = StaticService.sayFinal("hello");

    verify(StaticService.class);
    assertEquals("Expected and actual did not match", expected, actual);

    // Singleton still be mocked by now.
    try {
        StaticService.sayFinal("world");
            fail("Should throw AssertionError!");
    } catch (AssertionError e) {
        assertEquals("\n  Unexpected method call sayFinal(\"world\"):", 
            e.getMessage());
    }
}