How to use shouldRemoveAllInteractions method of org.mockitousage.basicapi.ResetInvocationsTest class

It seems that deprecated is void verify(VerificationMode mode, Verification verification) while void verify(Verification verification, VerificationMode mode) is still fine so you can just use the verify method like

dummyStatic.verify(
    () -> SomePublicClass.myPublicStaticFunc(anyInt()),
    times(1)
);

I've used the following dependency: testImplementation "org.mockito:mockito-inline:3.12.1".

It seems that with mockito-core you will not be able to mock this because you'll receive

The used MockMaker SubclassByteBuddyMockMaker does not support the creation of static mocks

What do you need most:

1. The ability to make sure that somebody doesn't inherit from your class, OR
2. The ability to make sure that your code is testable using your mocking framework of choice?

Generally, I believe that you don't need to enforce (1). For me, testability (2), is far more important. What fits your situation best?

I changed TestCompile to androidTestCompile and it's worked without problems.

testCompile 'junit:junit:4.12'

to

androidTestCompile 'junit:junit:4.12'

You don't need MockRestServiceServer object. The annotation is @InjectMocks not @Inject. Below is an example code that should work

@RunWith(MockitoJUnitRunner.class)
public class SomeServiceTest {
    @Mock
    private RestTemplate restTemplate;

    @InjectMocks
    private SomeService underTest;

    @Test
    public void testGetObjectAList() {
        ObjectA myobjectA = new ObjectA();
        //define the entity you want the exchange to return
        ResponseEntity<List<ObjectA>> myEntity = new ResponseEntity<List<ObjectA>>(HttpStatus.ACCEPTED);
        Mockito.when(restTemplate.exchange(
            Matchers.eq("/objects/get-objectA"),
            Matchers.eq(HttpMethod.POST),
            Matchers.<HttpEntity<List<ObjectA>>>any(),
            Matchers.<ParameterizedTypeReference<List<ObjectA>>>any())
        ).thenReturn(myEntity);

        List<ObjectA> res = underTest.getListofObjectsA();
        Assert.assertEquals(myobjectA, res.get(0));
    }

You have two options: Matching "any value but one", and overriding stubbing. (I suppose you could also use an Answer for complex custom behavior, but that's overkill for situations like this one.)

Stubbing any value except a given value

Mockito's AdditionalMatchers class offers a number of useful matchers, including operators such as not. This would allow you to set behavior for all values except for a specific value (or expression).

when(foo.bar(1)).thenReturn(99);
when(foo.bar(not(eq(1)))).thenThrow(new IllegalArgumentException());

Be careful to note that operators must be used with matchers instead of values, possibly requiring Matchers.eq as an explicit equals matcher, due to Mockito's argument matcher stack:

/* BAD */  when(foo.bar(not(  1  ))).thenThrow(new IllegalArgumentException());
/* GOOD */ when(foo.bar(not(eq(1)))).thenThrow(new IllegalArgumentException());

Overriding stubbing

For stubbing, the last-defined matching chain wins. This allows you to set up general test fixture behavior in a @Before method and override it in individual test cases if you wish, but also implies that order matters in your stubbing calls.

when(foo.baz(anyInt())).thenReturn("A", "B");  /* or .thenReturn("A").thenReturn("B"); */
when(foo.baz(9)).thenReturn("X", "Y");

foo.baz(6); /* "A" because anyInt() is the last-defined chain */
foo.baz(7); /* "B" as the next return value of the first chain */
foo.baz(8); /* "B" as Mockito repeats the final chain action forever */

foo.baz(9); /* "X" because the second chain matches for the value 9 */
foo.baz(9); /* "Y" forever because the second chain action still matches */

Consequently, you should never see the two stubs in the order listed in the question, because if a general match immediately follows a specific match then the specific match will never be used (and may as well be deleted).

Beware that you'll sometimes need to change syntax to doAnswer when overriding spies or dangerous stubbed behavior. Mockito knows not to count calls to when for verification or for advancing along thenVerb chains, but exceptions could still cause your test to fail.

/* BAD: the call to foo.bar(1) will throw before Mockito has a chance to stub it! */
when(foo.bar(anyInt())).thenThrow(new IllegalArgumentException());
when(foo.bar(1)).thenReturn(99);

/* GOOD: Mockito has a chance to deactivate behavior during stubbing. */
when(foo.bar(anyInt())).thenThrow(new IllegalArgumentException());
doReturn(99).when(foo).bar(1);

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.

The problem is on your test class Before method you are instantiating new controller

@Before
    public void setup() {
        categoryController = new CategoryController();
        mockMvc = MockMvcBuilders.standaloneSetup(categoryController).build();
    }

Here is how I do test for Controller

Controller Class :

@Controller
public class CategoryController {

    private SimpleCategoryDAO simpleCategoryDAO;
    private SimpleGifDAO simpleGifDAO;

    @Autowired
    public void setSimpleGifDAO(SimpleGifDAO simpleGifDAO) {
        this.simpleGifDAO = simpleGifDAO;
    }

    @Autowired
    public void setSimpleCategoryDAO(SimpleCategoryDAO simpleCategoryDAO) {
        this.simpleCategoryDAO = simpleCategoryDAO;
    }

    @RequestMapping("/categories")
    public String getAllCategories(ModelMap modelMap) {
        modelMap.put("categories", simpleCategoryDAO.getAllCategories());
        return "categories";
    }

    @RequestMapping("/category/{categoryID}")
    public String getGifsByCategoryID(@PathVariable int categoryID, ModelMap modelMap) {
        modelMap.put("gifs", simpleGifDAO.findGifsByCategoryID(categoryID));
        modelMap.put("category", simpleCategoryDAO.getCategoryByID(categoryID));
        return "category";
    }
}

Notice I'm using setter injection here not field injection. You can also use constructor injection ( preferred way for me).

In you test class

@RunWith(MockitoJUnitRunner.class)
public class CategoryControllerTest {

    private MockMvc mockMvc;

    @Mock
    private SimpleCategoryDAO simpleCategoryDAO;

    @Before
    public void setup() {
        final CategoryController categoryController = new CategoryController();

        //notice here I'm setting the mocked dao here
        // if you didn't use @RunWith(MockitoJUnitRunner.class)
        // you can do: simpleCategoryDAO = Mockito.mock(SimpleCategoryDAO.class);

        categoryController.setSimpleCategoryDAO(simpleCategoryDAO);

        mockMvc = MockMvcBuilders.standaloneSetup(categoryController).build();
    }

    @Test
    public void categories_ShouldRenderCategoriesView() throws Exception {
        List<Category> ALL_CATEGORIES = Arrays.asList(
                new Category(1, "Funny"),
                new Category(2, "JoyFul")
        );
        Mockito.when(simpleCategoryDAO.getAllCategories()).thenReturn(ALL_CATEGORIES);

        mockMvc.perform(get("/categories"))
                //.andExpect((MockMvcResultMatchers.model()).attribute("categories",ALL_CATEGORIES));
                .andExpect(MockMvcResultMatchers.view().name("categories"));
    }
}

Take a look at Before method on test. I'm setting the mocked DAO on the new instance of controller that I've created and then I'm creating the MockMvc using same instance of controller.

Mockito comes with a helper class to save you some reflection boiler plate code:

import org.mockito.internal.util.reflection.Whitebox;

//...

@Mock
private Person mockedPerson;
private Test underTest;

// ...

@Test
public void testMethod() {
    Whitebox.setInternalState(underTest, "person", mockedPerson);
    // ...
}

Update: Unfortunately the mockito team decided to remove the class in Mockito 2. So you are back to writing your own reflection boilerplate code, use another library (e.g. Apache Commons Lang), or simply pilfer the Whitebox class (it is MIT licensed).

Update 2: JUnit 5 comes with its own ReflectionSupport and AnnotationSupport classes that might be useful and save you from pulling in yet another library.

As pointed out by Timo, remove persistence-api-1.0.jar.

Just in case, here are the dependencies I'm using:

org.hibernate:hibernate-entitymanager:jar:3.5.3-Final:compile
+- org.hibernate:hibernate-core:jar:3.5.3-Final:compile
|  +- antlr:antlr:jar:2.7.6:compile
|  +- commons-collections:commons-collections:jar:3.2:compile
|  +- dom4j:dom4j:jar:1.6.1:compile
|  |  \- xml-apis:xml-apis:jar:1.0.b2:compile
|  \- javax.transaction:jta:jar:1.1:compile
+- org.hibernate:hibernate-annotations:jar:3.5.3-Final:compile
|  \- org.hibernate:hibernate-commons-annotations:jar:3.2.0.Final:compile
+- cglib:cglib:jar:2.2:compile
|  \- asm:asm:jar:3.1:compile
+- javassist:javassist:jar:3.9.0.GA:compile
\- org.hibernate.javax.persistence:hibernate-jpa-2.0-api:jar:1.0.0.Final:compile

I'm getting them from this single declaration in my pom.xml:

<dependency>
  <groupId>org.hibernate</groupId>
  <artifactId>hibernate-entitymanager</artifactId>
  <version>3.5.3-Final</version>
</dependency>

This should somehow answer your indulgent rant (if I rephrase: use Maven - or know what you're doing).