How to use StackTraceFilterTest class of org.mockito.internal.exceptions.stacktrace package

If you find yourself creating test classes (other than the classes containing actual tests), then you've defeated the purpose of having a mocking framework.

Create your mocks in your testcases:

 @Test
 public void testGreetingGenerator() {
      Person mockPerson = mock(Person.class);
      when(mockPerson.getName()).thenReturn("Alan");

      GreetingGenerator greeting = new GreetingGenerator(mockPerson);
      assertEquals("Hello Alan", greeting.getGreeting());
 }

If you are using the same mock in many tests, by all means make the mock a field, and put the mock creation into an @Before method.

 @Before
 public void setUp() {
      mockPerson = mock(Person.class);
      when(mockPerson.getName()).thenReturn("Alan");
 }

 @Test
 public void testGreetingGenerator() {
      GreetingGenerator greeting = new GreetingGenerator(mockPerson);
      assertEquals("Hello Alan", greeting.getGreeting());
 }

You can create a "basic" mock in setUp() and add more mocked behaviour to it in the individual testcases. Remember that setUp() gets called before each test, so you get fresh objects in each test.

If the mock creation gets too long and complex, it's fine to move it into a method (static or otherwise), and if necessary decompose that method into lots of smaller ones.

However, if your test code gets too complicated, think of it as a warning that perhaps the unit under test has too many dependencies and needs to be redesigned for testability.

Mocking is for unit testing. In the example above, the unit I am testing is GreetingGenerator. I am not intending to test Person here, so it is better to use a mock Person than a real one. That way if something about Person breaks, my Person tests will fail but my GreetingGenerator tests will keep working.

However that means that those tests don't validate that your Person and GreetingGenerator classes interoperate properly, and that's why as well as unit tests, you should have integration tests.

If you know a class is just for value objects, there's little benefit in using a mock.

At first you should check your test logic. Usually there are 3 cases. First, you are mocking the wrong method (you made a typo or someone changed tested code so that mocked method is no longer used). Second, your test is failing before this method is called. Third, your logic falls in wrong if/switch branch somewhere in the code so that mocked method is not called.

If this is the first case you always want to change the mocked method for the one used in the code. With the second and the third it depends. Usually you should just delete this mock if it has no use. But sometimes there are certain cases in parametrized tests, which should take this different path or fail earlier. Then you can split this test into two or more separate ones but that's not always good looking. 3 test methods with possibly 3 arguments providers can make your test look unreadable. In that case for JUnit 4 you silent this exception with either

@RunWith(MockitoJUnitRunner.Silent.class) 

annotation or if you are using rule approach

@Rule
public MockitoRule rule = MockitoJUnit.rule().strictness(Strictness.LENIENT);

or (the same behaviour)

@Rule
public MockitoRule rule = MockitoJUnit.rule().silent();

For JUnit 5 tests you can silence this exception using this annotation provided in mockito-junit-jupiter package:

@ExtendWith(MockitoExtension.class)
@MockitoSettings(strictness = Strictness.LENIENT)
class JUnit5MockitoTest {
}

Your problem is that when you use a collection in a for-each loop, its iterator() method gets called; and you haven't stubbed that particular method.

Instead of mocking the list, I strongly recommend you just pass a real list, where the elements are just your mocked TracedPath, as many times as you want it. Something like

listOfPaths = Arrays.asList(mockTracedPath, mockTracedPath, mockTracedPath);

A POST request normally passes its param in its body. So I cannot understand what you expect by giving both a param and a content for same request.

So here, you can simply do:

    mockMvc.perform(
        post("/usermgmt/createCloudCredential").contentType(
            MediaType.APPLICATION_JSON).content(json)).andExpect(
        status().isOk());

If you need to pass the parameter "username=aricloud_admin", add it to the JSON string, or alternatively, pass it explicitly as a query string:

    mockMvc.perform(
        post("/usermgmt/createCloudCredential?username=aricloud_admin")
            .contentType(MediaType.APPLICATION_JSON).content(json))
            .andExpect(status().isOk());

When you say

@Mock
Fruit fruit;

You tell Mockito: the fruit variable should be an instance of Fruit. Mockito will dynamically create a class which implements Fruit (this class is Fruit$$EnhancerByMockitoWithCGLIB$$b8254f54), and create an instance of this class. There's no reason for this class to be an instance of AppleFruit, since you didn't tell Mockito that the object had to be of type AppleFruit.

Declare it as AppleFruit, and it will be of type AppleFruit.

I don't know of other benefits offhand, but I want to address 2 of your sub-questions (and this is way too long for a comment):

allow mocking without dependency injection - this one isn't clear to me. Can you elaborate?

I think this came from the Motivation wiki page where they describe a way of refactoring code to not invoke static methods to make it testable. For a concrete example of what I think they're getting at, let's say you have this code and you want to test the method mocking the behaviour of the static method, without using powermock:

public class MyClass {
     public void doGetString() {
         ...
         OtherClass.getString(); //It's complex and scary and needs mocking!
         ...
     }
}

One solution, would be to pull the static invocation into its own object, then inject an object that can be mocked come test time. For example, without using other frameworks, this could look like:

public class MyClass {
     public static class StringGetter {
         public getString() {
             return OtherClass.getString();                 
         }
     }

     private final StringGetter getter;

     //Existing Constructor
     public MyClass() {
         this(new StringGetter());
     }

     //DI Constructor
     MyClass(StringGetter getter) {
         this.getter = getter;
     }

     public void doGetString() {
         ...
         getter.getString();
         ...
     }
}

I've seperated the behaviour of my method from the behaviour of the static invocation, and can use the DI constructor to inject mocks easily at test time. Of course with powermock I could just mock the static method in place, and run with it.

And do I need to sacrifice something when using PowerMock?

Physically no, but I'd say philosophically yes :). The below are my opinions, and I try to give good reasons behind them, but of course they are opinions so take them with a grain of salt:

The potentially scary thing that is happening with PowerMock is that in order to accomplish the feats of mocking private and static methods, they are using a custom class loader (which shouldn't be present at runtime in production) and changing the bytecode of your classes. Arguably, this should not matter with the vast majority of classes most of the time, but if you think about it, if the bytecode has changed, and certain side effects are no longer present, you're effectively testing different Classes albiet based upon your existing Classes. Yes this is a very academic argument.

You can somewhat mitigate this first argument by having good comprehensive integration and higher level tests that don't use PowerMock. In this way you can be more confident in the behaviours of your objects even if your unit tests are using PowerMock.

The other argument I have against PowerMock, is that it could almost too easily become a crutch. I agree that PowerMock can help with testing code that uses legacy code and other code that you do not have control over. However I would argue that when you have control over the classes that you need to mock, you should avoid its use. If you write a class with a private method or static method that you need to explicitly mock in order to test other methods, my gut instinct would say that this method may be doing too much and should be refactored and broken up. Having PowerMock already available in a project, you may be tempted to just mock it and move on, which would mitigate the pain that should encourage you to refactor the same. Yes there are sometimes due to various technical and non-technical constraints this is not possible, but it's good to solve pain points instead of avoid them :)

To directly answer your question, yes, you can mock some methods without mocking others. This is called a partial mock. See the Mockito documentation on partial mocks for more information.

For your example, you can do something like the following, in your test:

Stock stock = mock(Stock.class);
when(stock.getPrice()).thenReturn(100.00);    // Mock implementation
when(stock.getQuantity()).thenReturn(200);    // Mock implementation
when(stock.getValue()).thenCallRealMethod();  // Real implementation

In that case, each method implementation is mocked, unless specify thenCallRealMethod() in the when(..) clause.

There is also a possibility the other way around with spy instead of mock:

Stock stock = spy(Stock.class);
when(stock.getPrice()).thenReturn(100.00);    // Mock implementation
when(stock.getQuantity()).thenReturn(200);    // Mock implementation
// All other method call will use the real implementations

In that case, all method implementation are the real one, except if you have defined a mocked behaviour with when(..).

There is one important pitfall when you use when(Object) with spy like in the previous example. The real method will be called (because stock.getPrice() is evaluated before when(..) at runtime). This can be a problem if your method contains logic that should not be called. You can write the previous example like this:

Stock stock = spy(Stock.class);
doReturn(100.00).when(stock).getPrice();    // Mock implementation
doReturn(200).when(stock).getQuantity();    // Mock implementation
// All other method call will use the real implementations

Another possibility may be to use org.mockito.Mockito.CALLS_REAL_METHODS, such as:

Stock MOCK_STOCK = Mockito.mock( Stock.class, CALLS_REAL_METHODS );

This delegates unstubbed calls to real implementations.

However, with your example, I believe it will still fail, since the implementation of getValue() relies on quantity and price, rather than getQuantity() and getPrice(), which is what you've mocked.

Another possibility is to avoid mocks altogether:

@Test
public void getValueTest() {
    Stock stock = new Stock(100.00, 200);
    double value = stock.getValue();
    assertEquals("Stock value not correct", 100.00*200, value, .00001);
}

it is because of the version conflict between PowerMockito and Mockito artifacts. "MockCreationSettings.isUsingConstructor" method is removed in new versions, so you need to be sure you are using correct versions. e.g use PowerMockito version 1.6.2 with Mockito version 1.10.19 (this version has that missing method)

How about

when( method-call ).thenReturn( value1, value2, value3 );

You can put as many arguments as you like in the brackets of thenReturn, provided they're all the correct type. The first value will be returned the first time the method is called, then the second answer, and so on. The last value will be returned repeatedly once all the other values are used up.