How to use AtLeastXNumberOfInvocationsChecker class of org.mockito.internal.verification.checkers package

You cannot return anyString(), which is a matcher. It has to be a real string instance, like "foo".

The primary uses for DI as a technique are :

It leads to a code that is easier to test ( using Mocking ). This means that in order to use mocking frameworks ( Mockito etc ) , you should be using more of DI. If you dont use DI and write code that instantiates objects directly - then practically you cannot use Mockito to mock your dependencies.

Lets say you write code to play an Orchestra. Your main class depends upon so many other classes ( that other people wrote perhaps ).

Lets say you wrote this :

public class Orchestra {
  private Drums drum;
  private Violin violin;
  private Guitar guitar;

public Orchestra() {
    drum = new Drum();
    violin = new Violin();
    guitar = new Guitar();
}

public Music play(){
    // use above in some way to run your orchestra
    // start with violin 
    // add some guitar and then bring in the drums too
}

}

Now you want to ensure that your logic in play works accurately. When you run your class you see the music is not what you are expecting. ( maybe the drummming is starting right at the start ). You want to test the logic of your code play. How would you do that here ? You have no control over your dependencies. You dont know if there was an issue with code of Drum or your own logic in play().

You would want to mock out Drum here. But you cannot do that easily. Because your code does not use DI. Its instantiating the Drum directly inside.

Now lets use DI and see how it helps.

public class Orchestra {
    private Drums drum;
    private Violin violin;
    private Guitar guitar;

    public Orchestra(Drums d,Violin v, Guitar g ) {
        drum = d;
        violin = v;
        guitar = g;
    }

    public Music play(){
        // use above in some way to run your orchestra
    }

}

With this code , it becomes easy to mock out Drum in your test.

class TestOrchestra {

    public void testPlay(){
        Drum mockDrum = mock(Drum.class);
        Violin mockViolin = mock(Violin.class);
        Guitar mockGuitar = mock(Guitar.class);
        // add mock behaviour to above , here you control precisely what these dependencies will do inside your code

        Orchestra orch = new Orchestra(mockDrum, mockViolin,mockGuitar);
        // now play and test your logic

    }

}

The second advantage of using DI is that it helps vary implementations of bigger parts of your program without needing to go through your entire code.

Again - with reference to above , lets say you have been playing your orchestra using a particular type of guitar ( which is instantiated internally by your code).

Now you want to change to an brand new electric guitar.Without DI , you would have to open up your Orchestra class , check where you create the Guitar and change that line of code. You would have to ensure that other parts of your code are not changed inadvertently and test entire Orchestra to make sure things work correctly.

With DI , you could avoid all this. You just inject the new Guitar object into your constructor. Thats it. Because you have tested the new Guitar object on its own ( and it fulfills the contract of the interface Guitar - you can be rest assured that your Orchestra code is not broken by injecting this new Guitar. Thats quite a better improving your orchestra.

Just solved it by switching from Patterns.EMAIL_ADRESS.matcher() to PatternsCompat.EMAIL_ADRESS.matcher(). That should work.

This is a known issue with PowerMock (see, e.g., bug 597). In short, if you replace the rule module with the rule-agent module, it should do the trick. I.e., replace this requirement:

<dependency>
    <groupId>org.powermock</groupId>
    <artifactId>powermock-module-junit4-rule</artifactId>
    <version>${powermock-version}</version>
    <scope>test</scope>
</dependency>

With:

<dependency>
    <groupId>org.powermock</groupId>
    <artifactId>powermock-module-junit4-rule-agent</artifactId>
    <version>${powermock-version}</version>
    <scope>test</scope>
</dependency>

Just use the org.joda.time.DateTimeUtils#setCurrentMillisFixed method of JodaTime which was designed to fix new DateTime() to a different time than the current time. To return to the normal time use org.joda.time.DateTimeUtils#setCurrentMillisSystem afterwards. No mocking needed.

@Test
public void test() {
DateTimeUtils.setCurrentMillisFixed(10L);
// .. your code
}

@After
public void cleanup() {
// Make sure to cleanup afterwards
DateTimeUtils.setCurrentMillisSystem()
}

I got this when combining PowerMock with Mockito. Fixed by using compatible version as shown here: https://github.com/powermock/powermock/wiki/Mockito#supported-versions

The mocks that Mockito creates are generated class files; however, Mockito is designed for use in a JVM, so out of the box it generates .class files using cglib. Android Instrumentation test cases run on devices or emulators, so they need Dalvik .dex files.

You'll need to ensure you're including DexMaker on your classpath. The dexmaker-mockito Maven project seems to be right, though it depends on Mockito 1.10.5, which is a few versions behind at this point.

As a side note, unless you use the Android Testing Support Library, you will need to use JUnit3 semantics. You will not be able to use @Rule fields or custom test runners; you will also need to override setUp and tearDown (as opposed to @Before and @After annotations) and name your tests as testFooBar (as opposed to @Test annotations).

It is quite easy with Mockito:

@RunWith(MockitoJUnitRunner.class)
public class RuleIdValidatorTest {
    @Mock
    private RuleStore ruleStoreMock;

    @InjectMocks
    private RuleIdValidator ruleIdValidator;

    @Test
    public void someTest() {
        when(ruleStoreMock.doSomething("arg")).thenReturn("result");

        String actual = ruleIdValidator.doSomeThatDelegatesToRuleStore();

        assertEquals("result", actual);
    }
}

Read more about @InjectMocks in the Mockito javadoc or in a blog post that I wrote about the topic some time ago.

Available as of Mockito 1.8.3, enhanced in 1.9.0.

No, there is no reliable, supported way to do this. You assign a method reference to an instance of a functional interface, but that instance is cooked up by LambdaMetaFactory, and there is no way to drill into it to find the method you originally bound to.

Lambdas and method references in Java work quite differently than delegates in C#. For some interesting background, read up on invokedynamic.

Other answers and comments here show that it may currently be possible to retrieve the bound method with some additional work, but make sure you understand the caveats.