How to use matches method of org.mockito.internal.hamcrest.HamcrestArgumentMatcher class

You can absolutely inject mocks on MyLauncher in your test. I am sure if you show what mocking framework you are using someone would be quick to provide an answer. With mockito I would look into using @RunWith(MockitoJUnitRunner.class) and using annotations for myLauncher. It would look something like what is below.

@RunWith(MockitoJUnitRunner.class)
public class MyLauncherTest
    @InjectMocks
    private MyLauncher myLauncher = new MyLauncher();

    @Mock
    private MyService myService;

    @Test
    public void someTest() {

    }
}

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")
}

The sample works if you remove the PowerMock dependencies. The issue is that the versions of Mockito and PowerMock used are incompatible with each other. For PowerMock 2.x you need at least Mockito 2.8.9+. PowerMock provides a compatibility list that shows what version of PowerMock is compatible with what version of Mockito. Fix up the versions to be compatible with each other and your sample will start to work.

Well yes - the actual code of Foo doesn't matter, because you're mocking it... and Mockito doesn't know there's meant to be a relationship between setName and getName. It doesn't assume that it should store the argument to setName and return it when getName is called... it could do that, but it doesn't as far as I'm aware. The mock provided by Mockito just allows you to specify what happens when methods are called on it, and check what was called later on. Instead of calling setName, you could mock a call to getName() and specify what it should return...

... or you could just use Foo directly instead of mocking it. Don't think you have to mock everything in your tests. Just mock (or fake) things that are awkward when you're using the real class, e.g. because it uses the file system or network.

You are only asking Mockito to call the real thing on clear, the underlying object is still a fake created by Mockito for you. If you need a real LinkedList then just use the LinkedList - only the most heated purist of BDD would tell you to mock everything around you. I mean, you are not mocking Strings are you?

Mockito author himself has said that calling the real thing should be used scarcely, usually only for testing a legacy code.

If you need to spy on the real object (track the invocations) then Mockito has a feature for this too:

List list = new LinkedList();
List spy = spy(list);

With spy, you can still stub a method if you need. It basically works like a mock, but isn't ;)

I had a similar issue and it was suggested to me to create a Resources.java class that Produced an Entity Manager.

@Stateful
public class Resources implements Serializable {

    @PersistenceContext (type = PersistenceContextType.TRANSACTION)
    private EntityManager entityManager;

    @Produces
    public EntityManager getEntityManager() {
        return entityManager;
    }

}

I'm still not exactly sure why this solution worked for me... but it did.

v/r Ace

when(myObject.someMethod()).thenReturn(someMockObject);
// run test
verify(myObject, times(n)).someMethod();

See the documentation for more conversion examples.

There are different ways to use Mockito - I'll go through them one by one.

Manually

Creating mocks manually with Mockito::mock works regardless of the JUnit version (or test framework for that matter).

Annotation Based

Using the @Mock-annotation and the corresponding call to MockitoAnnotations::initMocks to create mocks works regardless of the JUnit version (or test framework for that matter but Java 9 could interfere here, depending on whether the test code ends up in a module or not).

Mockito Extension

JUnit 5 has a powerful extension model and Mockito recently published one under the group / artifact ID org.mockito : mockito-junit-jupiter.

You can apply the extension by adding @ExtendWith(MockitoExtension.class) to the test class and annotating mocked fields with @Mock. From MockitoExtension's JavaDoc:

@ExtendWith(MockitoExtension.class)
public class ExampleTest {

    @Mock
    private List list;

    @Test
    public void shouldDoSomething() {
        list.add(100);
    }

}

The MockitoExtension documentation describes other ways to instantiate mocks, for example with constructor injection (if you rpefer final fields in test classes).

No Rules, No Runners

JUnit 4 rules and runners don't work in JUnit 5, so the MockitoRule and the Mockito runner can not be used.

The easiest way may be to combine Mockitos Answer with lambdas, streams and iterators. The resulting code is

Iterator<Integer> values = Stream.iterate(0, n -> n + 100).iterator();
when(myClass.myMethod()).thenAnswer(i -> values.next());

The code can be made a little more efficient if you use an IntStream and a PrimitiveIterator.OfInt as the iterator type, but that is probably overkill for a unit test...