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

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

i think that our previous conversation diverged a bit from the point i was
trying to make.

here are three possible versions of a test method:

// VERSION A //
public void testUpdate() throws Exception {

  myMockStatement.setExpectedQueryString(UPDATE_QUERY);
  myMockStatement.setExpectedExecuteCalls(1);

  mySQLObj.setMyInstanceVariable("different value"); // marks isChanged
  SQLUtils.update(myMockConnection, objs);

  myMockStatement.verify();
}

// VERSION B //
public void testUpdate() throws Exception {

  myMockResultSet.setupRows( { ... } );

  myMockResultSet.setExpectedUpdateRowCalls(1);  // this line tests
implementation details

  mySQLObj.setMyInstanceVariable("different value"); // marks isChanged
  SQLUtils.update(myMockConnection, objs);

  myMockResultSet.verify();
}

// VERSION C //
public void testUpdate() throws Exception {

  myMockResultSet.setupRows( { ... } );
  SQLObject[] objs = SQLUtils.fetch(myMockConnection, IDS_TO_FETCH);
  objs[0].setMyInstanceVariable("different value"); // marks isChanged
  SQLUtils.update(myMockConnection, objs);

  SQLObject[] objs = SQLUtils.fetch(myMockConnection, IDS_TO_FETCH);
  assertEquals("different value", objs[0].getMyInstanceVariable());
}


Version A seems very MockObjects-ish.  i think it is clear that Version A
assumes that you are performing the update by calling executeUpdate() on a
statement.

Version B also seems very MockObjects-ish.  version B, on the other hand,
assumes that you are performing the update by getting a resultset and
calling rs.updateRow() on the resultset.

Version C doesn't seem very MockObjects-ish, primarily because you'd have to
implement a lot of not-so-mock functionality in your mock objects to make it
work.

but Version C is the only one of the three that really specifies what i am
trying to test.  if i am writing a function to update a bunch of objects in
a database, what i care about is that the objects got updated correctly.  i
don't care HOW they got updated.  Version A and B both test that the update
happened a certain way.

maybe this whole dilemma is the fault of JDBC, because it provides 2
different *interfaces* for accomplishing the same functionality...?  but on
the other hand, it would be nice to be able to write test code that would
pass even if i decided to re-implement my update() by making a raw socket
connection to the SQL server...

-brian















> Yups!
>
>
>
>
> > so, all your updates will be done using an SQL query, rather than by
using
> > an updatable result set, right?
>
> > -brian
>