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?










share|improve this question






















  • Check my updated answer. Looks like it's what you need.
    – ETO
    Nov 11 at 11:06















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?










share|improve this question






















  • Check my updated answer. Looks like it's what you need.
    – ETO
    Nov 11 at 11:06













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?










share|improve this question













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






share|improve this question













share|improve this question











share|improve this question




share|improve this question










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


















  • 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












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.






share|improve this answer























  • 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 @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




















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)






share|improve this answer























  • 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











Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















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

























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.






share|improve this answer























  • 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 @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

















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.






share|improve this answer























  • 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 @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















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.






share|improve this answer














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.







share|improve this answer














share|improve this answer



share|improve this answer








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 @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




















  • 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 @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


















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














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)






share|improve this answer























  • 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















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)






share|improve this answer























  • 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













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)






share|improve this answer














@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)







share|improve this answer














share|improve this answer



share|improve this answer








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


















  • 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


















draft saved

draft discarded




















































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.




draft saved


draft discarded














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





















































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







Popular posts from this blog

List item for chat from Array inside array React Native

Thiostrepton

Caerphilly