How to use refInstance method of org.mockitoinline.bugs.SelfSpyReferenceMemoryLeakTest class

The maven surefire plugin also needs to read the files as UTF-8 otherwise it wont do it :). I had tried something like this before but with the wrong Element in <configuration/>...

Proper configuration:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <configuration>
        <argLine>-Dfile.encoding=UTF-8</argLine>
    </configuration>
</plugin>

You can't do this with Mockito, but Apache Commons actually has a way to do this using one of its built in utilities. You can put this in a function in JUnit that is run after Mockito injects the rest of the mocks but before your test cases run, like this:

@InjectMocks
MyClass myClass;

@Before
public void before() throws Exception {
    FieldUtils.writeField(myClass, "fieldName", fieldValue, true);
}

I've just fixed same issue, and my workaround was this:

create a dummy Application and set theme inside onCreate():

public class TestApplication extends Application {

    @Override
    public void onCreate() {
        super.onCreate();
        setTheme(R.style.AppTheme); //or just R.style.Theme_AppCompat
    }
}

then inside the test you specify the application class in config:

@RunWith(RobolectricTestRunner.class)
@Config(application = TestApplication.class)
public class YourActivityTest {
    //tests
}

There is no public API in Mockito for mock injection. Plus as this annotation is mostly driven on the way things are laid out in a test, it is fairly related to the initialization phase of the test.

Though it might change at some point in the future.

However Mockito annotated fields can be initialized either by the MockitoJUnitRunner or by MockitoAnnotations.initMocks(). They both create mock instances and perform injection.

Also I see in your code that you are using @Autowired - hence spring stuff, probably configured via XML. @InjectMocks wasn't really developed to work with other dependency injection frameworks, as the development was driven by unit test use cases, not integration tests.

You might want to take a look at springockito, which is another project that tries to ease Mockito mock creation in Spring.

Hope that helps

So for me the first thing you need to do is to extract the part of the code that can throw a ClassNotFoundException in order to be able to easily mock it, something like:

public Class<? extends NetworkResponseBuilder> getNetworkResponseBuilderClass()
    throws ClassNotFoundException {
    // Your logic here
}

Then you can test a real factory instance using Mockito.spy to be able to redefine the behavior of the method getNetworkResponseBuilderClass() as next:

public void testFactoryIfNetworkResponseBuilderNotFound() {
    Factory factory = spy(new Factory());
    when(factory.getNetworkResponseBuilderClass()).thenThrow(
        new ClassNotFoundException()
    );
    // The rest of your test here
}

public void testFactoryIfNetworkResponseBuilderFound() {
    Factory factory = spy(new Factory());
    when(factory.getNetworkResponseBuilderClass()).thenReturn(
        OkHttpNetworkResponse.Builder.class
    );
    // The rest of your test here
}

More details about Mockito.spy.

You shouldn't do this. Mockito is a really well-designed, simple to learn, extremely well-documented, and almost de-facto standard framework. And it's type-safe and doesn't need reflection, which makes tests easy to read and understand.

Let your developers learn the real Mockito and use its API directly. They'll be happy to use it because it will have a better, easier to use and more flexible design than your own super-api, and they'll know that they won't learn Mockito for nothing because they'll probably use it in other projects or even other jobs.

Mockito doesn't need another proprietary API on top of it. My suggested alternative is thus to forget about this and teach Mockito to your developers.

The parentheses are poorly placed.

You need to use:

doThrow(new Exception()).when(mockedObject).methodReturningVoid(...);
                                          ^

and NOT use:

doThrow(new Exception()).when(mockedObject.methodReturningVoid(...));
                                                                   ^

This is explained in the documentation

As Tim alluded to in the comments, your goal is to make sure that your software behaves according to the specifications. One such specification might be that the maximum length is always 10, at which point it'd be unnecessary to test a world where length is 5 or 15.

Here's the question to ask yourself: How likely is it that you'll want to use your class with a different value of the "constant"? I've quoted "constant" here because if you vary the value programmatically, it's not really a constant at all, is it? :)

• If your value will never ever change, you could not use a symbolic constant at all, just comparing to 10 directly and testing based on (say) 0, 3, 10, and 11. This might make your code and tests a little hard to understand ("Where did the 10 come from? Where did the 11 come from?"), and will certainly make it hard to change if you ever do have reason to vary the number. Not recommended.

• If your value will probably never change, you could use a private named constant (i.e. a static final field), as you have. Then your code will be easy enough to change, though your tests won't be able to automatically adjust the way your code would.

  • You could also relax to package-private visibility, which would be available to tests in the same package. Javadoc (e.g. /** Package-private for testing. */) or documentation annotations (e.g. @VisibleForTesting) may help make your intentions clear. This is a nice option if your constant value is intended to be opaque and unavailable outside of your class, like an URL template or authentication token.

  • You could even make it a public constant, which would be available to consumers of your class as well. For your example of a constant Length, a public static final field is probably best, on the assumption that other pieces of your system may want to know about that (e.g. for UI validation hints or error messages).

• If your value is likely to change you could accept it per-instance, as in new Length(10) or new Length().setMaxLength(10). (I consider the former to be a form of dependency injection, counting the constant integer as a dependency.) This is also a good idea if you wanted to use a different value in tests, such as using a maximum length of 2048 in production but testing against 10 for practicality's sake. To make a flexible length validator, this option is probably a good upgrade from a static final field.

• Only if your value is likely to change during your instance's lifetime would I bother with a DI-style value provider. At that point, you can query the value interactively, so it doesn't behave at all like a constant. For "length", that'd be obvious overkill, but maybe not for "maximum allowed memory", "maximum simultaneous connections", or some other pseudo-constants like that.

In short, you'll have to decide how much control you need, and then you can pick the most straightforward choice from there; as a "default", you may want to make it a visible field or constructor parameter, as those tend to have good balance of simplicity and flexibility.

I think it should be

verify(mockBar, times(2)).doSomething(...)

Sample from mockito javadoc:

ArgumentCaptor<Person> peopleCaptor = ArgumentCaptor.forClass(Person.class);
verify(mock, times(2)).doSomething(peopleCaptor.capture());

List<Person> capturedPeople = peopleCaptor.getAllValues();
assertEquals("John", capturedPeople.get(0).getName());
assertEquals("Jane", capturedPeople.get(1).getName());