[Mockobjects-java-users] simulating vs. reproducing behavior

[Brian D. <br...@dl...>]

hi,
i'm fairly new to Mock Objects, and trying to wrap my head around where to
draw the line between simulating and reproducing behavior.

I came across some code in our system recently which, under certain
conditions, calls deleteRow() on a ResultSet and then immediately calls
updateRow() on the same ResultSet. I wasn't sure off the top of my head
whether that was "legal", whether it should throw an exception, or what the
expected behavior was according to the JDBC spec.  I was in the middle of
trying to hack up a mock implementation for updatable result sets, so it
seemed particularly relevant.  My first instinct is that, whatever correct
behavior is, the MockResultSet should mimic it. So if, for example,
"rs.deleteRow(); rs.updateRow();" should throw an exception, then my
MockResultSet should throw an exception. But the more details of that nature
you try to simulate, the closer you get to really reproducing the
functionality instead of just emulating it. To *really* simulate correct
behavior, then after you update a ResultSet you should be able to iterate
back over it and see the updates you just made reflected in your get()
calls. But by that point, you have practically created a real implementation
of a ResultSet! Where do you draw the line?

In a related vein, it seems to me that limiting yourself to emulating the
functionality in as minimal a way as possible, does tend to make your test
code rely on implementation details.  For example, we have some code which
provides an abstraction over the process of inserting/updating/deleting
several rows of a table based on the states of objects which "know" how to
read and write themselves to/from the table. Now, this code might work by
using an updatable result set, or it might work by calling executeUpdate
methods on a statement. Using mock objects, I have to test things like the
particular query string used, or the number of execute calls, or (if it uses
an updatable result set) the number of updateRow(), insertRow(), or
deleteRow() calls. All of these tests will break if I change the internal
implementation details of the code I am trying to test. It seems that to
test the abstraction instead of the implementation, you have to do a more
thorough job of emulating the behavior than the Mock Objects pattern really
advocates.

Does anyone have comments or advice about this? To make things concrete:
let's say I'm implementing a mock updatable result set. Would you code it so
that the update methods actually alter the table rows? Or would you just
provide for expectations of how many times updateRow(), etc. get called?

-brian