Mockito Repetition in Stubbing and Verification

It seems that in certain cases, EasyMock stubbing can take the place of verification. Take the following trivial example:

Class A:

public class A {

    private B b;



    public A(B b) {

        this.b = b;

    }



    int main(int input) {

        return b.timesThree(input + 4);

    }

}

Class B:

public class B {

    int timesThree(int input) {

        return input * 3;

    }

}

Class ATest:

@ExtendWith(MockitoExtension.class)

public class ATest {

    @Mock

    B b;



    @InjectMocks

    A a;



    @Test

    void testMain() {

        doReturn(21).when(b).timesThree(7);



        int result = a.main(3);

        assertEquals(21, result);



        verify(b).timesThree(7);

    }



}

Is there a point to the verify call? The when call already asserts the input parameter to b.timesThree() is 7.

asked Jan 2 at 20:46

Paul I

345149

In your example, you don't need to call doReturn() and should call verify() since you're dealing with primitives specifically.

– Pankaj Gadge
Jan 2 at 20:49

3

Well, if you absolutely want to make sure that the call to timesThree has been made, then it's useful. Otherwise, it's not. Without the verify, the test would pass if the code was replaced by return 21;. This is a highly unlikely situation, so I wouldn't bother.

– JB Nizet
Jan 2 at 20:51

@PankajGadge wouldn't that cause the B mock to return 0 when its timesThree method is called? In any event, the primitives were just to keep the question simple, but my main intent was to understand what the value of using verify is in these particular types of cases.

– Paul I
Jan 2 at 20:55

1

If you are also unit testing that B.timesThree() works as expected (which you should be) then I would think it's unneeded to verify it's being called in addition to the stub if it's working as expected. Seems overkill in this case.

– Stalemate Of Tuning
Jan 2 at 20:57

add a comment |

It seems that in certain cases, EasyMock stubbing can take the place of verification. Take the following trivial example:

Class A:

public class A {

    private B b;



    public A(B b) {

        this.b = b;

    }



    int main(int input) {

        return b.timesThree(input + 4);

    }

}

Class B:

public class B {

    int timesThree(int input) {

        return input * 3;

    }

}

Class ATest:

@ExtendWith(MockitoExtension.class)

public class ATest {

    @Mock

    B b;



    @InjectMocks

    A a;



    @Test

    void testMain() {

        doReturn(21).when(b).timesThree(7);



        int result = a.main(3);

        assertEquals(21, result);



        verify(b).timesThree(7);

    }



}

Is there a point to the verify call? The when call already asserts the input parameter to b.timesThree() is 7.

asked Jan 2 at 20:46

Paul I

345149

In your example, you don't need to call doReturn() and should call verify() since you're dealing with primitives specifically.

– Pankaj Gadge
Jan 2 at 20:49

3

Well, if you absolutely want to make sure that the call to timesThree has been made, then it's useful. Otherwise, it's not. Without the verify, the test would pass if the code was replaced by return 21;. This is a highly unlikely situation, so I wouldn't bother.

– JB Nizet
Jan 2 at 20:51

@PankajGadge wouldn't that cause the B mock to return 0 when its timesThree method is called? In any event, the primitives were just to keep the question simple, but my main intent was to understand what the value of using verify is in these particular types of cases.

– Paul I
Jan 2 at 20:55

1

If you are also unit testing that B.timesThree() works as expected (which you should be) then I would think it's unneeded to verify it's being called in addition to the stub if it's working as expected. Seems overkill in this case.

– Stalemate Of Tuning
Jan 2 at 20:57

add a comment |

It seems that in certain cases, EasyMock stubbing can take the place of verification. Take the following trivial example:

Class A:

public class A {

    private B b;



    public A(B b) {

        this.b = b;

    }



    int main(int input) {

        return b.timesThree(input + 4);

    }

}

Class B:

public class B {

    int timesThree(int input) {

        return input * 3;

    }

}

Class ATest:

@ExtendWith(MockitoExtension.class)

public class ATest {

    @Mock

    B b;



    @InjectMocks

    A a;



    @Test

    void testMain() {

        doReturn(21).when(b).timesThree(7);



        int result = a.main(3);

        assertEquals(21, result);



        verify(b).timesThree(7);

    }



}

Is there a point to the verify call? The when call already asserts the input parameter to b.timesThree() is 7.

asked Jan 2 at 20:46

Paul I

345149

It seems that in certain cases, EasyMock stubbing can take the place of verification. Take the following trivial example:

Class A:

public class A {

    private B b;



    public A(B b) {

        this.b = b;

    }



    int main(int input) {

        return b.timesThree(input + 4);

    }

}

Class B:

public class B {

    int timesThree(int input) {

        return input * 3;

    }

}

Class ATest:

@ExtendWith(MockitoExtension.class)

public class ATest {

    @Mock

    B b;



    @InjectMocks

    A a;



    @Test

    void testMain() {

        doReturn(21).when(b).timesThree(7);



        int result = a.main(3);

        assertEquals(21, result);



        verify(b).timesThree(7);

    }



}

Is there a point to the verify call? The when call already asserts the input parameter to b.timesThree() is 7.

java junit mockito

asked Jan 2 at 20:46

Paul I

345149

asked Jan 2 at 20:46

Paul I

345149

asked Jan 2 at 20:46

Paul I

345149

asked Jan 2 at 20:46

Paul I

345149

asked Jan 2 at 20:46

Paul I

345149

In your example, you don't need to call doReturn() and should call verify() since you're dealing with primitives specifically.

– Pankaj Gadge
Jan 2 at 20:49

3

Well, if you absolutely want to make sure that the call to timesThree has been made, then it's useful. Otherwise, it's not. Without the verify, the test would pass if the code was replaced by return 21;. This is a highly unlikely situation, so I wouldn't bother.

– JB Nizet
Jan 2 at 20:51

@PankajGadge wouldn't that cause the B mock to return 0 when its timesThree method is called? In any event, the primitives were just to keep the question simple, but my main intent was to understand what the value of using verify is in these particular types of cases.

– Paul I
Jan 2 at 20:55

1

If you are also unit testing that B.timesThree() works as expected (which you should be) then I would think it's unneeded to verify it's being called in addition to the stub if it's working as expected. Seems overkill in this case.

– Stalemate Of Tuning
Jan 2 at 20:57

add a comment |

In your example, you don't need to call doReturn() and should call verify() since you're dealing with primitives specifically.

– Pankaj Gadge
Jan 2 at 20:49

3

Well, if you absolutely want to make sure that the call to timesThree has been made, then it's useful. Otherwise, it's not. Without the verify, the test would pass if the code was replaced by return 21;. This is a highly unlikely situation, so I wouldn't bother.

– JB Nizet
Jan 2 at 20:51

@PankajGadge wouldn't that cause the B mock to return 0 when its timesThree method is called? In any event, the primitives were just to keep the question simple, but my main intent was to understand what the value of using verify is in these particular types of cases.

– Paul I
Jan 2 at 20:55

1

If you are also unit testing that B.timesThree() works as expected (which you should be) then I would think it's unneeded to verify it's being called in addition to the stub if it's working as expected. Seems overkill in this case.

– Stalemate Of Tuning
Jan 2 at 20:57

In your example, you don't need to call doReturn() and should call verify() since you're dealing with primitives specifically.

– Pankaj Gadge
Jan 2 at 20:49

Well, if you absolutely want to make sure that the call to timesThree has been made, then it's useful. Otherwise, it's not. Without the verify, the test would pass if the code was replaced by return 21;. This is a highly unlikely situation, so I wouldn't bother.

– JB Nizet
Jan 2 at 20:51

@PankajGadge wouldn't that cause the B mock to return 0 when its timesThree method is called? In any event, the primitives were just to keep the question simple, but my main intent was to understand what the value of using verify is in these particular types of cases.

– Paul I
Jan 2 at 20:55

If you are also unit testing that B.timesThree() works as expected (which you should be) then I would think it's unneeded to verify it's being called in addition to the stub if it's working as expected. Seems overkill in this case.

– Stalemate Of Tuning
Jan 2 at 20:57

add a comment |

1 Answer
1

active

oldest

votes

In this case no. It comes down to what you are really trying to assert in the test.

Here you are trying to test that when main method is called with a value 2 things should happen

timesThree should be called with value+4

value returned from timesThree should be returned by your main function

Since in your test the below three lines is enough to assert both the above cases you don't need a verify here.

doReturn(21).when(b).timesThree(7);

int result = a.main(3);

assertEquals(21, result);

The easiest way to find out if your test is good enough is by commenting out parts of your implementation and making your test fail (TDD). As long as you get a failing test you are good.

Ex: change 4 to 5 - test fails, remove input test fails

Suppose your timesThree method did not return a value, but instead stored it somewhere

int main(int input) {

//Stores value somwhere

    b.timesThree(input + 4);

}

Here you test has to assert that timesThree is called once with the value 7.
In this case you need a verify, since you will never be able to get a failing test without verify.

Also on a side note one of the comments mentioned "the test would pass if the code was replaced by return 21;"

To proof your test against this consider using a random integer instead of hardcoding values. This will make sure there is no accidental hard coding in your implementation.
Example library for random intgers
https://commons.apache.org/proper/commons-lang/javadocs/api-2.6/org/apache/commons/lang/math/RandomUtils.html#nextInt()

edited Jan 3 at 0:07

answered Jan 2 at 23:39

user1576261

342

add a comment |

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',
autoActivateHeartbeat: false,
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

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54012956%2fmockito-repetition-in-stubbing-and-verification%23new-answer', 'question_page');
}
);

Post as a guest

Name

Required, but never shown

1 Answer
1

active

oldest

votes

1 Answer
1

active

oldest

votes

In this case no. It comes down to what you are really trying to assert in the test.

Here you are trying to test that when main method is called with a value 2 things should happen

timesThree should be called with value+4

value returned from timesThree should be returned by your main function

Since in your test the below three lines is enough to assert both the above cases you don't need a verify here.

doReturn(21).when(b).timesThree(7);

int result = a.main(3);

assertEquals(21, result);

The easiest way to find out if your test is good enough is by commenting out parts of your implementation and making your test fail (TDD). As long as you get a failing test you are good.

Ex: change 4 to 5 - test fails, remove input test fails

Suppose your timesThree method did not return a value, but instead stored it somewhere

int main(int input) {

//Stores value somwhere

    b.timesThree(input + 4);

}

Here you test has to assert that timesThree is called once with the value 7.
In this case you need a verify, since you will never be able to get a failing test without verify.

Also on a side note one of the comments mentioned "the test would pass if the code was replaced by return 21;"

edited Jan 3 at 0:07

answered Jan 2 at 23:39

user1576261

342

add a comment |

In this case no. It comes down to what you are really trying to assert in the test.

Here you are trying to test that when main method is called with a value 2 things should happen

timesThree should be called with value+4

value returned from timesThree should be returned by your main function

Since in your test the below three lines is enough to assert both the above cases you don't need a verify here.

doReturn(21).when(b).timesThree(7);

int result = a.main(3);

assertEquals(21, result);

The easiest way to find out if your test is good enough is by commenting out parts of your implementation and making your test fail (TDD). As long as you get a failing test you are good.

Ex: change 4 to 5 - test fails, remove input test fails

Suppose your timesThree method did not return a value, but instead stored it somewhere

int main(int input) {

//Stores value somwhere

    b.timesThree(input + 4);

}

Here you test has to assert that timesThree is called once with the value 7.
In this case you need a verify, since you will never be able to get a failing test without verify.

Also on a side note one of the comments mentioned "the test would pass if the code was replaced by return 21;"

edited Jan 3 at 0:07

answered Jan 2 at 23:39

user1576261

342

add a comment |

In this case no. It comes down to what you are really trying to assert in the test.

Here you are trying to test that when main method is called with a value 2 things should happen

timesThree should be called with value+4

value returned from timesThree should be returned by your main function

Since in your test the below three lines is enough to assert both the above cases you don't need a verify here.

doReturn(21).when(b).timesThree(7);

int result = a.main(3);

assertEquals(21, result);

The easiest way to find out if your test is good enough is by commenting out parts of your implementation and making your test fail (TDD). As long as you get a failing test you are good.

Ex: change 4 to 5 - test fails, remove input test fails

Suppose your timesThree method did not return a value, but instead stored it somewhere

int main(int input) {

//Stores value somwhere

    b.timesThree(input + 4);

}

Here you test has to assert that timesThree is called once with the value 7.
In this case you need a verify, since you will never be able to get a failing test without verify.

Also on a side note one of the comments mentioned "the test would pass if the code was replaced by return 21;"

edited Jan 3 at 0:07

answered Jan 2 at 23:39

user1576261

342

In this case no. It comes down to what you are really trying to assert in the test.

Here you are trying to test that when main method is called with a value 2 things should happen

timesThree should be called with value+4

value returned from timesThree should be returned by your main function

Since in your test the below three lines is enough to assert both the above cases you don't need a verify here.

doReturn(21).when(b).timesThree(7);

int result = a.main(3);

assertEquals(21, result);

The easiest way to find out if your test is good enough is by commenting out parts of your implementation and making your test fail (TDD). As long as you get a failing test you are good.

Ex: change 4 to 5 - test fails, remove input test fails

Suppose your timesThree method did not return a value, but instead stored it somewhere

int main(int input) {

//Stores value somwhere

    b.timesThree(input + 4);

}

Here you test has to assert that timesThree is called once with the value 7.
In this case you need a verify, since you will never be able to get a failing test without verify.

Also on a side note one of the comments mentioned "the test would pass if the code was replaced by return 21;"

edited Jan 3 at 0:07

answered Jan 2 at 23:39

user1576261

342

edited Jan 3 at 0:07

answered Jan 2 at 23:39

user1576261

342

answered Jan 2 at 23:39

user1576261

342

answered Jan 2 at 23:39

user1576261

342

add a comment |

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.

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Name

Required, but never shown

Name

Required, but never shown

This page is only for reference, If you need detailed information, please check here

Search This Blog

Ufyukyu