Repository: mockito/mockito
Issue: Documentation update - MockitoJUnit.strictness(STRICT_STUBS) does not do verifyNoMoreInteractions
Labels: docs
please contribute

### Problem

Our documentation about "strict stubs" does not clearly indicate the difference between "strict mocks" (described at #1097). In short, "strict stubs" are not "strict mocks", e.g. we detect unused or incorrectly declared stubs but we don't force the user to verify all interactions.

### Suggested implementation

Suggest an update to the Javadoc that would make things clear? Perhaps on Strictness type or on Strictness.STRICT_STUBS enum value.

### Original report

I'd expect to let this test fail:

```
public class SomeTest {
  @Rule public final MockitoRule mockitoRule = MockitoJUnit.rule().strictness(STRICT_STUBS);

  @Mock Something something;

  @Test public void something() {
    Single.just(1)
        .doOnSuccess(something::add)
        .test()
        .assertResult(1);
  }

  interface Something {
    void add(int i);
  }
}
```

when using `strictness(STRICT_STUBS)`, since I'm not verifying that `something.add(1)` was called.

Adding:

```
  @After public void tearDown() {
    verifyNoMoreInteractions(something);
  }
```

yields the desire red unit test:

```
org.mockito.exceptions.verification.NoInteractionsWanted: 
No interactions wanted here:
-> at tearDown(SomeTest.java:27)
But found this interaction on mock 'something':
-> at io.reactivex.internal.operators.single.SingleDoOnSuccess$DoOnSuccess.onSuccess(SingleDoOnSuccess.java:53)
```

Is this by design?

Junit Version: 4.12
Mockito Version: 2.8.9


Issue comments:
Yes, it is by design.

"Strict stubs" are not "strict mocks", e.g. we detect unused or incorrectly declared stubs but we don't force the user to verify all interactions.

If above is not clear in the documentation, can you suggest and update to the Javadoc that would make this clear? Perhaps on Strictness type or on Strictness.STRICT_STUBS enum value.
Are there any plans for `Strict mocks` where the above would be detected?
>Are there any plans for Strict mocks where the above would be detected?

Yes, we should start supporting strict mocks. I gave a talk at Devoxx conference in San Jose in March and I collected even more feedback for offering strict mocks as an alternative. We have a ticket open at #649 on this but so far we didn't accumulate enough energy to get started on this.

You motivated me to start working on this. I'll commit to produce a design spec for #649 so that it is ready to work on by an eager contributor. How does it sound? :)
> I gave a talk at Devoxx conference in San Jose in March and I collected even more feedback for offering strict mocks as an alternative.

That's also where I learned from the `MockitoRule` and the different options. Thanks for that!

> How does it sound? :)

Awesome.

I'd also very much prefer something along the lines of:
 `Mockito.enableStrictMode();`

Where you opt in for strict modes by default and then maybe can opt out for particular mocks.

Do you plan to integrate the above static method call into the MockitoRule so that you can maybe do something like:
`@Rule public final MockitoRule mockitoRule = MockitoJUnit.rule().strictness(STRICT_MOCKS);` that has the behavior of `STRICT_STUBS` and strict mocking?

The design spec is ready at #1097. Do you want to contribute? :)
I'm definitely interested. I might have some time. Would it also be okay to start with a POC and from there go and implement out all of the details? 
>Would it also be okay to start with a POC and from there go and implement out all of the details?

Absolutely! Feel free to submit PR with a POC for early review.
`release/2.x` is the correct branch to do so, right?
Yes please :)
Op ma 29 mei 2017 om 18:14 schreef Niklas Baudy <notifications@github.com>:

> release/2.x is the correct branch to do so, right?
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> <https://github.com/mockito/mockito/issues/1086#issuecomment-304694849>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AFrDb9S1OMV6VFvnHQkIS66COktib-yMks5r-u7ngaJpZM4NcKVl>
> .
>


Pull request review comments:

Patch that resolved the issue:
diff --git a/src/main/java/org/mockito/quality/Strictness.java b/src/main/java/org/mockito/quality/Strictness.java
index 4e1126ae85..c9da8d367c 100644
--- a/src/main/java/org/mockito/quality/Strictness.java
+++ b/src/main/java/org/mockito/quality/Strictness.java
@@ -80,7 +80,8 @@ public enum Strictness {
      *      <li>Cleaner, more DRY tests ("Don't Repeat Yourself"):
      *          If you use {@link org.mockito.Mockito#verifyNoMoreInteractions(Object...)}
      *          you no longer need to explicitly verify stubbed invocations.
-     *          They are automatically verified for you.</li>
+     *          They are automatically verified for you. However if you have more invocations,
+     *          the test won't fail since it won't check that there are no more interactions on that stub.</li>
      *  </ul>
      *
      * For more information see {@link Strictness}.


Test patch: