In response to a much nicer blog entry, that can be found here.
There are actually several distinct "tests" that make up usual unit tests, among them two that really do stand out:
Mock objects are for the purpose of testing method flows. A method flow is a series of message transmissions to dependent objects.
The control flow logic inside the method(the ifs and whiles) will alter the flow
BTW: I partly use message transmission instead of method invocation to include other kinds of "not really method invocations" like "exceptions".
The author of the afore mentioned post is quite right with his observation, that his test resembles the method under test quite closely, except, of course, for the control flow code(loops, conditionals). And that is absolutely desired, as he is testing mainly the "method flow" - there is not much computation necessary in JDBC code like this anyway.
It is tempting to raise the objection that a change in the order of messages sent to another object inside the method under test will result in a failing test, but it is easy to perceive the fact that the order of messages send to ONE object SHOULD be relevant. If it is not, well then there is no point in changing the method under test, isn't there?
Even if the method under test send variuos messages to various distinct objects, the order will be relevant at some level of abstraction. Therefore mock-checking of the order of method invocations can be(and must be) adjusted, at least if multiple distinct objects are addressed by the method under test.
And nothing else is it, that the author proposes, although, a little more complicated, than necessary when using easymock, for what I know.
There are actually several distinct "tests" that make up usual unit tests, among them two that really do stand out:
- one kind of testing to test method flows,
- one to test some sort of computation.
Mock objects are for the purpose of testing method flows. A method flow is a series of message transmissions to dependent objects.
The control flow logic inside the method(the ifs and whiles) will alter the flow
- in repsonse to the parameters of the method call parameters passed by calling the method under test,
- depending on the state of the object that contains the method under test and
- the return values of the external method calls(aka responses to the messages sent).
BTW: I partly use message transmission instead of method invocation to include other kinds of "not really method invocations" like "exceptions".
The author of the afore mentioned post is quite right with his observation, that his test resembles the method under test quite closely, except, of course, for the control flow code(loops, conditionals). And that is absolutely desired, as he is testing mainly the "method flow" - there is not much computation necessary in JDBC code like this anyway.
It is tempting to raise the objection that a change in the order of messages sent to another object inside the method under test will result in a failing test, but it is easy to perceive the fact that the order of messages send to ONE object SHOULD be relevant. If it is not, well then there is no point in changing the method under test, isn't there?
Even if the method under test send variuos messages to various distinct objects, the order will be relevant at some level of abstraction. Therefore mock-checking of the order of method invocations can be(and must be) adjusted, at least if multiple distinct objects are addressed by the method under test.
And nothing else is it, that the author proposes, although, a little more complicated, than necessary when using easymock, for what I know.
Comments
http://coffeedrivenjava.blogspot.com/2006/09/mock-objects-revisisted.html
More information can be found at http://www.oo-testen.de.