Mockito's @After and verifyNoMoreInteractions
up vote
2
down vote
favorite
I want to make sure every test verifies all the interactions with its mocks, so I just added a method annotated with @After with a verifyNoMoreInteractions with all the mocks as arguments.
@After
public void after(){
verifyNoMoreInteractions(mock1,mock2,mock3,...)
}
It works, but if an interaction occurs where none was expected, how can you know which test is the problematic one?
java junit mockito
add a comment |
up vote
2
down vote
favorite
I want to make sure every test verifies all the interactions with its mocks, so I just added a method annotated with @After with a verifyNoMoreInteractions with all the mocks as arguments.
@After
public void after(){
verifyNoMoreInteractions(mock1,mock2,mock3,...)
}
It works, but if an interaction occurs where none was expected, how can you know which test is the problematic one?
java junit mockito
Check my updated answer. Looks like it's what you need.
– ETO
Nov 11 at 11:06
add a comment |
up vote
2
down vote
favorite
up vote
2
down vote
favorite
I want to make sure every test verifies all the interactions with its mocks, so I just added a method annotated with @After with a verifyNoMoreInteractions with all the mocks as arguments.
@After
public void after(){
verifyNoMoreInteractions(mock1,mock2,mock3,...)
}
It works, but if an interaction occurs where none was expected, how can you know which test is the problematic one?
java junit mockito
I want to make sure every test verifies all the interactions with its mocks, so I just added a method annotated with @After with a verifyNoMoreInteractions with all the mocks as arguments.
@After
public void after(){
verifyNoMoreInteractions(mock1,mock2,mock3,...)
}
It works, but if an interaction occurs where none was expected, how can you know which test is the problematic one?
java junit mockito
java junit mockito
asked Nov 9 at 22:15
CCC
99632037
99632037
Check my updated answer. Looks like it's what you need.
– ETO
Nov 11 at 11:06
add a comment |
Check my updated answer. Looks like it's what you need.
– ETO
Nov 11 at 11:06
Check my updated answer. Looks like it's what you need.
– ETO
Nov 11 at 11:06
Check my updated answer. Looks like it's what you need.
– ETO
Nov 11 at 11:06
add a comment |
2 Answers
2
active
oldest
votes
up vote
3
down vote
accepted
You're misusing method verifyNoMoreInteractions(). It should be called inside each test you want to verify.
From the other hand @After is supposed to be used for cleaning/closing the resourses used by your test methods.
What you need is a custom TestWatcher rule. See below an example of such rule:
public class VerifyNoMoreInteractionsRule extends TestWatcher {
private final List<Object> mocks = new ArrayList<>();
public void add(Object mock){
mocks.add(mock);
}
@Override
protected void succeeded(Description description) {
verifyNoMoreInteractions(mocks.toArray());
}
}
Then you can use it in your unit tests:
@RunWith(MockitoJUnitRunner.class)
public class VerifyTest {
@Rule
public VerifyNoMoreInteractionsRule noMoreInteractionsRule = new VerifyNoMoreInteractionsRule();
@Mock
private YourMock yourMock;
@Mock
private AnotherMock anotherMock;
@Before
public void setUp(){
// Register the mocks you want to verify after each test
noMoreInteractionsRule.add(yourMock);
noMoreInteractionsRule.add(anotherMock);
}
@Test
public void test(){
// Put your ordinary test code here
}
}
The rule will be applied to each test.
love it, but how do you know which test is the one that's failing?
– CCC
Nov 12 at 18:19
The rule will make it fail. So it'll look as it failed itself. The same effect as putting verifier inside each of your tests.
– ETO
Nov 12 at 18:55
is there a way to know which test is the one that's missing the verifications?
– CCC
Nov 12 at 19:07
If you declare the@Rulein your test class then in will be applied to all methods annotated with@Test.
– ETO
Nov 12 at 20:10
I actually meant showing the failing test as part of the error message: @Override protected void succeeded(Description description) { mocks.stream().forEach((mock)-> { try { verifyNoMoreInteractions(mock); } catch (NoInteractionsWanted e) { System.err.println("failed test " + description.getDisplayName()); throw e; } }); }
– CCC
Nov 12 at 20:54
add a comment |
up vote
1
down vote
@After is executed right after each test of this class finished execution. Regardless if the test failed or not. Then if errors happen in the @After method it could cover/hide the errors happened in the test method...
Note that @AfterClass Is executed after all tests of this class finished execution.
Generally speaking I found it is a good style to have a behavioural Test split in three parts- call it A/A/A or call it Given/When/Then
Arrange / Given part:
Setup up objects and behaviour
Act or When:
Execute implementation
Assert or Then:
Verify behaviour and results (Hint: this is where the verifyNoMoreInteractions goes)
I actually go with the Given/When/Then arrangement, and in the Then part I place the verify as usual, but since I wanted to make sure that every person that creates a test verifies all the interactions, I thought it could be a good idea to have the verifyNoMoreInteractions in the @After method
– CCC
Nov 9 at 22:42
You can do it like that, why not. But I like to set up most resources within the test itself, so the After method won’t know the mocks I want to test.
– michaeak
Nov 9 at 22:44
Yeah that's the way I've always done it, but some tests are just way too large, so I thought about having the mocks as attributes of the class instead rather than declaring them in each test, then I thought about the verifyNoMoreInteractions in the @After method
– CCC
Nov 10 at 0:09
If the test is too large I would check if the class/method is doing too much, keyword separation of concerns
– michaeak
Nov 10 at 8:33
add a comment |
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
3
down vote
accepted
You're misusing method verifyNoMoreInteractions(). It should be called inside each test you want to verify.
From the other hand @After is supposed to be used for cleaning/closing the resourses used by your test methods.
What you need is a custom TestWatcher rule. See below an example of such rule:
public class VerifyNoMoreInteractionsRule extends TestWatcher {
private final List<Object> mocks = new ArrayList<>();
public void add(Object mock){
mocks.add(mock);
}
@Override
protected void succeeded(Description description) {
verifyNoMoreInteractions(mocks.toArray());
}
}
Then you can use it in your unit tests:
@RunWith(MockitoJUnitRunner.class)
public class VerifyTest {
@Rule
public VerifyNoMoreInteractionsRule noMoreInteractionsRule = new VerifyNoMoreInteractionsRule();
@Mock
private YourMock yourMock;
@Mock
private AnotherMock anotherMock;
@Before
public void setUp(){
// Register the mocks you want to verify after each test
noMoreInteractionsRule.add(yourMock);
noMoreInteractionsRule.add(anotherMock);
}
@Test
public void test(){
// Put your ordinary test code here
}
}
The rule will be applied to each test.
love it, but how do you know which test is the one that's failing?
– CCC
Nov 12 at 18:19
The rule will make it fail. So it'll look as it failed itself. The same effect as putting verifier inside each of your tests.
– ETO
Nov 12 at 18:55
is there a way to know which test is the one that's missing the verifications?
– CCC
Nov 12 at 19:07
If you declare the@Rulein your test class then in will be applied to all methods annotated with@Test.
– ETO
Nov 12 at 20:10
I actually meant showing the failing test as part of the error message: @Override protected void succeeded(Description description) { mocks.stream().forEach((mock)-> { try { verifyNoMoreInteractions(mock); } catch (NoInteractionsWanted e) { System.err.println("failed test " + description.getDisplayName()); throw e; } }); }
– CCC
Nov 12 at 20:54
add a comment |
up vote
3
down vote
accepted
You're misusing method verifyNoMoreInteractions(). It should be called inside each test you want to verify.
From the other hand @After is supposed to be used for cleaning/closing the resourses used by your test methods.
What you need is a custom TestWatcher rule. See below an example of such rule:
public class VerifyNoMoreInteractionsRule extends TestWatcher {
private final List<Object> mocks = new ArrayList<>();
public void add(Object mock){
mocks.add(mock);
}
@Override
protected void succeeded(Description description) {
verifyNoMoreInteractions(mocks.toArray());
}
}
Then you can use it in your unit tests:
@RunWith(MockitoJUnitRunner.class)
public class VerifyTest {
@Rule
public VerifyNoMoreInteractionsRule noMoreInteractionsRule = new VerifyNoMoreInteractionsRule();
@Mock
private YourMock yourMock;
@Mock
private AnotherMock anotherMock;
@Before
public void setUp(){
// Register the mocks you want to verify after each test
noMoreInteractionsRule.add(yourMock);
noMoreInteractionsRule.add(anotherMock);
}
@Test
public void test(){
// Put your ordinary test code here
}
}
The rule will be applied to each test.
love it, but how do you know which test is the one that's failing?
– CCC
Nov 12 at 18:19
The rule will make it fail. So it'll look as it failed itself. The same effect as putting verifier inside each of your tests.
– ETO
Nov 12 at 18:55
is there a way to know which test is the one that's missing the verifications?
– CCC
Nov 12 at 19:07
If you declare the@Rulein your test class then in will be applied to all methods annotated with@Test.
– ETO
Nov 12 at 20:10
I actually meant showing the failing test as part of the error message: @Override protected void succeeded(Description description) { mocks.stream().forEach((mock)-> { try { verifyNoMoreInteractions(mock); } catch (NoInteractionsWanted e) { System.err.println("failed test " + description.getDisplayName()); throw e; } }); }
– CCC
Nov 12 at 20:54
add a comment |
up vote
3
down vote
accepted
up vote
3
down vote
accepted
You're misusing method verifyNoMoreInteractions(). It should be called inside each test you want to verify.
From the other hand @After is supposed to be used for cleaning/closing the resourses used by your test methods.
What you need is a custom TestWatcher rule. See below an example of such rule:
public class VerifyNoMoreInteractionsRule extends TestWatcher {
private final List<Object> mocks = new ArrayList<>();
public void add(Object mock){
mocks.add(mock);
}
@Override
protected void succeeded(Description description) {
verifyNoMoreInteractions(mocks.toArray());
}
}
Then you can use it in your unit tests:
@RunWith(MockitoJUnitRunner.class)
public class VerifyTest {
@Rule
public VerifyNoMoreInteractionsRule noMoreInteractionsRule = new VerifyNoMoreInteractionsRule();
@Mock
private YourMock yourMock;
@Mock
private AnotherMock anotherMock;
@Before
public void setUp(){
// Register the mocks you want to verify after each test
noMoreInteractionsRule.add(yourMock);
noMoreInteractionsRule.add(anotherMock);
}
@Test
public void test(){
// Put your ordinary test code here
}
}
The rule will be applied to each test.
You're misusing method verifyNoMoreInteractions(). It should be called inside each test you want to verify.
From the other hand @After is supposed to be used for cleaning/closing the resourses used by your test methods.
What you need is a custom TestWatcher rule. See below an example of such rule:
public class VerifyNoMoreInteractionsRule extends TestWatcher {
private final List<Object> mocks = new ArrayList<>();
public void add(Object mock){
mocks.add(mock);
}
@Override
protected void succeeded(Description description) {
verifyNoMoreInteractions(mocks.toArray());
}
}
Then you can use it in your unit tests:
@RunWith(MockitoJUnitRunner.class)
public class VerifyTest {
@Rule
public VerifyNoMoreInteractionsRule noMoreInteractionsRule = new VerifyNoMoreInteractionsRule();
@Mock
private YourMock yourMock;
@Mock
private AnotherMock anotherMock;
@Before
public void setUp(){
// Register the mocks you want to verify after each test
noMoreInteractionsRule.add(yourMock);
noMoreInteractionsRule.add(anotherMock);
}
@Test
public void test(){
// Put your ordinary test code here
}
}
The rule will be applied to each test.
edited Nov 11 at 11:06
answered Nov 9 at 22:29
ETO
1,118117
1,118117
love it, but how do you know which test is the one that's failing?
– CCC
Nov 12 at 18:19
The rule will make it fail. So it'll look as it failed itself. The same effect as putting verifier inside each of your tests.
– ETO
Nov 12 at 18:55
is there a way to know which test is the one that's missing the verifications?
– CCC
Nov 12 at 19:07
If you declare the@Rulein your test class then in will be applied to all methods annotated with@Test.
– ETO
Nov 12 at 20:10
I actually meant showing the failing test as part of the error message: @Override protected void succeeded(Description description) { mocks.stream().forEach((mock)-> { try { verifyNoMoreInteractions(mock); } catch (NoInteractionsWanted e) { System.err.println("failed test " + description.getDisplayName()); throw e; } }); }
– CCC
Nov 12 at 20:54
add a comment |
love it, but how do you know which test is the one that's failing?
– CCC
Nov 12 at 18:19
The rule will make it fail. So it'll look as it failed itself. The same effect as putting verifier inside each of your tests.
– ETO
Nov 12 at 18:55
is there a way to know which test is the one that's missing the verifications?
– CCC
Nov 12 at 19:07
If you declare the@Rulein your test class then in will be applied to all methods annotated with@Test.
– ETO
Nov 12 at 20:10
I actually meant showing the failing test as part of the error message: @Override protected void succeeded(Description description) { mocks.stream().forEach((mock)-> { try { verifyNoMoreInteractions(mock); } catch (NoInteractionsWanted e) { System.err.println("failed test " + description.getDisplayName()); throw e; } }); }
– CCC
Nov 12 at 20:54
love it, but how do you know which test is the one that's failing?
– CCC
Nov 12 at 18:19
love it, but how do you know which test is the one that's failing?
– CCC
Nov 12 at 18:19
The rule will make it fail. So it'll look as it failed itself. The same effect as putting verifier inside each of your tests.
– ETO
Nov 12 at 18:55
The rule will make it fail. So it'll look as it failed itself. The same effect as putting verifier inside each of your tests.
– ETO
Nov 12 at 18:55
is there a way to know which test is the one that's missing the verifications?
– CCC
Nov 12 at 19:07
is there a way to know which test is the one that's missing the verifications?
– CCC
Nov 12 at 19:07
If you declare the
@Rule in your test class then in will be applied to all methods annotated with @Test.– ETO
Nov 12 at 20:10
If you declare the
@Rule in your test class then in will be applied to all methods annotated with @Test.– ETO
Nov 12 at 20:10
I actually meant showing the failing test as part of the error message: @Override protected void succeeded(Description description) { mocks.stream().forEach((mock)-> { try { verifyNoMoreInteractions(mock); } catch (NoInteractionsWanted e) { System.err.println("failed test " + description.getDisplayName()); throw e; } }); }
– CCC
Nov 12 at 20:54
I actually meant showing the failing test as part of the error message: @Override protected void succeeded(Description description) { mocks.stream().forEach((mock)-> { try { verifyNoMoreInteractions(mock); } catch (NoInteractionsWanted e) { System.err.println("failed test " + description.getDisplayName()); throw e; } }); }
– CCC
Nov 12 at 20:54
add a comment |
up vote
1
down vote
@After is executed right after each test of this class finished execution. Regardless if the test failed or not. Then if errors happen in the @After method it could cover/hide the errors happened in the test method...
Note that @AfterClass Is executed after all tests of this class finished execution.
Generally speaking I found it is a good style to have a behavioural Test split in three parts- call it A/A/A or call it Given/When/Then
Arrange / Given part:
Setup up objects and behaviour
Act or When:
Execute implementation
Assert or Then:
Verify behaviour and results (Hint: this is where the verifyNoMoreInteractions goes)
I actually go with the Given/When/Then arrangement, and in the Then part I place the verify as usual, but since I wanted to make sure that every person that creates a test verifies all the interactions, I thought it could be a good idea to have the verifyNoMoreInteractions in the @After method
– CCC
Nov 9 at 22:42
You can do it like that, why not. But I like to set up most resources within the test itself, so the After method won’t know the mocks I want to test.
– michaeak
Nov 9 at 22:44
Yeah that's the way I've always done it, but some tests are just way too large, so I thought about having the mocks as attributes of the class instead rather than declaring them in each test, then I thought about the verifyNoMoreInteractions in the @After method
– CCC
Nov 10 at 0:09
If the test is too large I would check if the class/method is doing too much, keyword separation of concerns
– michaeak
Nov 10 at 8:33
add a comment |
up vote
1
down vote
@After is executed right after each test of this class finished execution. Regardless if the test failed or not. Then if errors happen in the @After method it could cover/hide the errors happened in the test method...
Note that @AfterClass Is executed after all tests of this class finished execution.
Generally speaking I found it is a good style to have a behavioural Test split in three parts- call it A/A/A or call it Given/When/Then
Arrange / Given part:
Setup up objects and behaviour
Act or When:
Execute implementation
Assert or Then:
Verify behaviour and results (Hint: this is where the verifyNoMoreInteractions goes)
I actually go with the Given/When/Then arrangement, and in the Then part I place the verify as usual, but since I wanted to make sure that every person that creates a test verifies all the interactions, I thought it could be a good idea to have the verifyNoMoreInteractions in the @After method
– CCC
Nov 9 at 22:42
You can do it like that, why not. But I like to set up most resources within the test itself, so the After method won’t know the mocks I want to test.
– michaeak
Nov 9 at 22:44
Yeah that's the way I've always done it, but some tests are just way too large, so I thought about having the mocks as attributes of the class instead rather than declaring them in each test, then I thought about the verifyNoMoreInteractions in the @After method
– CCC
Nov 10 at 0:09
If the test is too large I would check if the class/method is doing too much, keyword separation of concerns
– michaeak
Nov 10 at 8:33
add a comment |
up vote
1
down vote
up vote
1
down vote
@After is executed right after each test of this class finished execution. Regardless if the test failed or not. Then if errors happen in the @After method it could cover/hide the errors happened in the test method...
Note that @AfterClass Is executed after all tests of this class finished execution.
Generally speaking I found it is a good style to have a behavioural Test split in three parts- call it A/A/A or call it Given/When/Then
Arrange / Given part:
Setup up objects and behaviour
Act or When:
Execute implementation
Assert or Then:
Verify behaviour and results (Hint: this is where the verifyNoMoreInteractions goes)
@After is executed right after each test of this class finished execution. Regardless if the test failed or not. Then if errors happen in the @After method it could cover/hide the errors happened in the test method...
Note that @AfterClass Is executed after all tests of this class finished execution.
Generally speaking I found it is a good style to have a behavioural Test split in three parts- call it A/A/A or call it Given/When/Then
Arrange / Given part:
Setup up objects and behaviour
Act or When:
Execute implementation
Assert or Then:
Verify behaviour and results (Hint: this is where the verifyNoMoreInteractions goes)
edited Nov 10 at 9:41
answered Nov 9 at 22:24
michaeak
668314
668314
I actually go with the Given/When/Then arrangement, and in the Then part I place the verify as usual, but since I wanted to make sure that every person that creates a test verifies all the interactions, I thought it could be a good idea to have the verifyNoMoreInteractions in the @After method
– CCC
Nov 9 at 22:42
You can do it like that, why not. But I like to set up most resources within the test itself, so the After method won’t know the mocks I want to test.
– michaeak
Nov 9 at 22:44
Yeah that's the way I've always done it, but some tests are just way too large, so I thought about having the mocks as attributes of the class instead rather than declaring them in each test, then I thought about the verifyNoMoreInteractions in the @After method
– CCC
Nov 10 at 0:09
If the test is too large I would check if the class/method is doing too much, keyword separation of concerns
– michaeak
Nov 10 at 8:33
add a comment |
I actually go with the Given/When/Then arrangement, and in the Then part I place the verify as usual, but since I wanted to make sure that every person that creates a test verifies all the interactions, I thought it could be a good idea to have the verifyNoMoreInteractions in the @After method
– CCC
Nov 9 at 22:42
You can do it like that, why not. But I like to set up most resources within the test itself, so the After method won’t know the mocks I want to test.
– michaeak
Nov 9 at 22:44
Yeah that's the way I've always done it, but some tests are just way too large, so I thought about having the mocks as attributes of the class instead rather than declaring them in each test, then I thought about the verifyNoMoreInteractions in the @After method
– CCC
Nov 10 at 0:09
If the test is too large I would check if the class/method is doing too much, keyword separation of concerns
– michaeak
Nov 10 at 8:33
I actually go with the Given/When/Then arrangement, and in the Then part I place the verify as usual, but since I wanted to make sure that every person that creates a test verifies all the interactions, I thought it could be a good idea to have the verifyNoMoreInteractions in the @After method
– CCC
Nov 9 at 22:42
I actually go with the Given/When/Then arrangement, and in the Then part I place the verify as usual, but since I wanted to make sure that every person that creates a test verifies all the interactions, I thought it could be a good idea to have the verifyNoMoreInteractions in the @After method
– CCC
Nov 9 at 22:42
You can do it like that, why not. But I like to set up most resources within the test itself, so the After method won’t know the mocks I want to test.
– michaeak
Nov 9 at 22:44
You can do it like that, why not. But I like to set up most resources within the test itself, so the After method won’t know the mocks I want to test.
– michaeak
Nov 9 at 22:44
Yeah that's the way I've always done it, but some tests are just way too large, so I thought about having the mocks as attributes of the class instead rather than declaring them in each test, then I thought about the verifyNoMoreInteractions in the @After method
– CCC
Nov 10 at 0:09
Yeah that's the way I've always done it, but some tests are just way too large, so I thought about having the mocks as attributes of the class instead rather than declaring them in each test, then I thought about the verifyNoMoreInteractions in the @After method
– CCC
Nov 10 at 0:09
If the test is too large I would check if the class/method is doing too much, keyword separation of concerns
– michaeak
Nov 10 at 8:33
If the test is too large I would check if the class/method is doing too much, keyword separation of concerns
– michaeak
Nov 10 at 8:33
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53233957%2fmockitos-after-and-verifynomoreinteractions%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Check my updated answer. Looks like it's what you need.
– ETO
Nov 11 at 11:06