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

[Verma, N. (G. B. L529706) <Nit...@ge...>]

Hi Brian,

MockObject: are not just to emulating behavior of an object but also to
make us de-couple tests form the real systems! 

" My intent is to assert my logic not assert *is there is a network
connection* or *is the database up*"
When I need to assert some logic on the data I receive from the database 
I don't use mockobjects, as I need the real system!

Any comments...

Reagrds,

Nitin Verma

-----Original Message-----
From: Brian Denny [mailto:br...@dl...]
Sent: Friday, March 08, 2002 2:29 AM
To: moc...@li...
Subject: [Mockobjects-java-users] simulating vs. reproducing behavior



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



_______________________________________________
Mockobjects-java-users mailing list
Moc...@li...
https://lists.sourceforge.net/lists/listinfo/mockobjects-java-users


"THIS E-MAIL MESSAGE ALONG WITH ANY ATTACHMENTS IS INTENDED ONLY FOR THE
ADDRESSEE and may contain confidential and privileged information.
If the reader of this message is not the intended recipient,
you are notified that any dissemination, distribution or copy of this 
communication is strictly Prohibited. 
If you have received this message by error, please notify us 
immediately, return the original mail to the sender and delete the 
message from your system."