How to use shouldFailStubbingThrowableOnTheSameInvocationDueToAcceptableLimitation method of org.mockitousage.stubbing.StubbingWithThrowablesTest class

You may refactor your code a little bit. In the "Working with Legacy Code" book by Martin Fowler, he describes a technique of separating the external API (think Java Mail API) from your own application code. The technique is called "Wrap and Skin" and is pretty simple.

What you should do is simply:

1. Create an interface MySession (which is your own stuff) by extracting methods from the javax.mail.Session class.
2. Implement that interface by creating a concrete class (looking a bit like the original javax.mail.Session)
3. In each method DELEGATE the call to equivalent javax.mail.Session method
4. Create your mock class which implements MySession :-)
5. Update your production code to use MySession instead of javax.mail.Session

Happy testing!

EDIT: Also take a look at this blog post: http://www.mhaller.de/archives/18-How-to-mock-a-thirdparty-final-class.html

As Object.getClass() is final, you cannot mock that method with Mockito. I would strongly advice you to refactor your code to inject the class in another way. If that's not possible, you could try out powermock, where you could mock any final method. Object.getClass() is a bit special, so be sure to set MockGateway.MOCK_GET_CLASS_METHOD = true in powermock.

To verify the number of times it was invoked, use verify(spiedObject, times(x)).doSomething().

You should NOT be verifying the value returned from the spied object. It is not the object under test so why verify what it returns. Instead verify the behavior of the object under test in response to the value returned from the spy.

Also, if you don't KNOW what value will be returned by the spied object it would be better to use a mock instead of a spy.

I'll talk about Spring and @Transactional but the advise applies for many other frameworks also.

This is an inherent problem with proxy based aspects. It is discussed in the spring documentation here:

http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/aop.html#aop-understanding-aop-proxies

There are a number of possible solutions.

Refactor your classes to avoid the self-invocation calls that bypass the proxy.

The Spring documentation describes this as "The best approach (the term best is used loosely here)".

Advantages of this approach are its simplicity and that there are no ties to any framework. However, it may not be appropriate for a very transactional heavy code base as you'd end up with many trivially small classes.

Internally in the class get a reference to the proxy.

This can be done by injecting the proxy or with hard coded " AopContext.currentProxy()" call (see Spring docs above.).

This method allows you to avoid splitting the classes but in many ways negates the advantages of using the transactional annotation. My personal opinion is that this is one of those things that is a little ugly but the ugliness is self contained and might be the pragmatic approach if lots of transactions are used.

Switch to using AspectJ

As AspectJ does not use proxies then self-invocation is not a problem

This is a very clean method though - it is at the expense of introducing another framework. I've worked on a large project where AspectJ was introduced for this very reason.

Don't use @Transactional at all

Refactor your code to use manual transaction demarcation - possibly using the decorator pattern.

An option - but one that requires moderate refactoring, introducing additional framework ties and increased complexity - so probably not a preferred option

My Advice

Usually splitting up the code is the best answer and can also be good thing for seperation of concerns also. However, if I had a framework/application that heavily relied on nested transactions I would consider using AspectJ to allow self-invocation.

I've just finished comparing three BDD frameworks for Java. Obviously my findings have a fairly short use-by date.

Concordion

• Very flexible
• Very pretty report output
• Nice plugin framework
• Poorly documented. I had to read the source to figure it out (luckily its extremely good quality).
• Fixtures seemed likely to end up tightly coupled to the html.

EasyB

• Very shallow learning curve (even for non-Groovy Developers)
• Extremely powerful DBUnit integration
• Apparently no support for parameters (leads to either very vague stories or duplication between text and code (edit: actually there is but the documentation for it was very well hidden.)
• Story and Code are very tightly coupled (same file)
• Very basic report output
• Couldn't get IntelliJ plugin to work
• Inactive community (Maven plugin seems to have been broken for three months - not many code examples to draw on)

JBehave

• Extremely powerful and flexible (eg reduction of boiler-plate through composition of stories as pre-requisites)
• Extensive (if fragmented) documentation and examples
• Extensive (if overwhelming) support for different frameworks and environments
• Excellent separation of story files from code
• Looks to have a pretty active community and much more examples and discussion of it on web.
• Quite a steep learning curve (took me 3-4 times longer to figure out than Concordion/EasyB)

I didn't have the chance to try out Cuke4Duke of JDave as I would have liked, but will probably push for JBehave at this time.

It should be enough to name your mocks serviceA and serviceB. From Mockito documentation:

Property setter injection; mocks will first be resolved by type, then, if there is several property of the same type, by the match of the property name and the mock name.

In your example:

@InjectMocks ServiceCaller classUnderTest;

@Mock SomeService serviceA;
@Mock SomeService serviceB;

Note that it is not necessary to manually create class instance when using @InjectMocks.

Nevertheless I personally prefer injecting dependencies using constructor. It makes it easier to inject mocks in tests (just call a constructor with your mocks - without reflections tools or @InjectMocks (which is useful, but hides some aspects)). In addition using TDD it is clearly visible what dependencies are needed for the tested class and also IDE can generate your constructor stubs.

Spring Framework completely supports constructor injection:

@Bean
public class ServiceCaller {
    private final SomeService serviceA;
    private final SomeService serviceB;

    @Autowired
    public ServiceCaller(@Qualifier("serviceA") SomeService serviceA,
                         @Qualifier("serviceB") SomeService serviceB) { ... }

    ...
}

This code can be tested with:

@Mock SomeService serviceA;
@Mock SomeService serviceB;

//in a setup or test method
ServiceCaller classUnderTest = new ServiceCaller(serviceA, serviceB); 

Using @TestConfiguration rather than using the @MockBean might help to solve this problem.

@TestConfiguration
    static class Configuration {
        @Bean
        public BeanToMock name() {
            // return mock object           
        }
    }

And annotating the test class with @ContextConfiguration:

@ContextConfiguration(classes = TestClassName.Configuration.class)

Difference between a Spy and a Mock

When Mockito creates a mock – it does so from the Class of a Type, not from an actual instance. The mock simply creates a bare-bones shell instance of the Class, entirely instrumented to track interactions with it. On the other hand, the spy will wrap an existing instance. It will still behave in the same way as the normal instance – the only difference is that it will also be instrumented to track all the interactions with it.

In the following example – we create a mock of the ArrayList class:

@Test
public void whenCreateMock_thenCreated() {
    List mockedList = Mockito.mock(ArrayList.class);

    mockedList.add("one");
    Mockito.verify(mockedList).add("one");

    assertEquals(0, mockedList.size());
}

As you can see – adding an element into the mocked list doesn’t actually add anything – it just calls the method with no other side-effect. A spy on the other hand will behave differently – it will actually call the real implementation of the add method and add the element to the underlying list:

@Test
public void whenCreateSpy_thenCreate() {
    List spyList = Mockito.spy(new ArrayList());
    spyList.add("one");
    Mockito.verify(spyList).add("one");

    assertEquals(1, spyList.size());
}

Here we can surely say that the real internal method of the object was called because when you call the size() method you get the size as 1, but this size() method isn’t been mocked! So where does 1 come from? The internal real size() method is called as size() isn’t mocked (or stubbed) and hence we can say that the entry was added to the real object.

Source: http://www.baeldung.com/mockito-spy + self notes.

You could use a custom answer to do this

MyInterface myMock = mock(MyInterface.class);
Sky sky = buildRandomSkyColor();

when(myMock.methodWithNoArguments()).thenAnswer(new Answer<String>(){
    String answer(InvocationOnMock invocation) {
        if(sky.isBlue())
            return "blue";
        else
            return "gray";
    }
}