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

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

perhaps i should give a more concrete example.

i have this utility method to stick a bunch of objects in a database.
each object corresponds to a table row and "knows" how to read/write itself
into a table.

// pseudojava
public void update(Connection conn, SQLObject[] objs) {
  for (each obj in objs) {
    if (obj.isMarkedDeleted()) {
      // jdbc code to delete obj from table
    } else if (obj.isMarkedChanged()) {
      // jdbc code to update table row for obj
    } else if (obj.isMarkedNew()) {
      // jdbck code to insert obj into table
    } else {
      // do nothing
    }
  }
}

now i want to test this method. so i write something like:

public void testUpdate throws Exception {
  // object declarations and creation snipped
  obj1.markNew();
  obj2.markChanged();
  obj3.markDeleted();
  mockStatement.setExpectedExecuteCalls(3);
  dbUtility.update(mockConnection, new SQLObject[] { obj1, obj2, obj3 });
  mockStatement.verify();
}

hmm.  the above doesn't actually test that i did one insert, one delete, and
one update.
so i could do the three updates separately -- one for each object -- and
test the query string each time:

public void testUpdate throws Exception {
  // object declarations and creation snipped
  obj1.markNew();
  obj2.markChanged();
  obj3.markDeleted();

  mockStatement.setExpectedExecuteCalls(1);
  mockStatement.setExpectedQueryString(
      "INSERT INTO objecttable values ('this is painful')");
  dbUtility.update(mockConnection, new SQLObject[] { obj1 });
  mockStatement.verify();

  mockStatement.setExpectedExecuteCalls(1);
  mockStatement.setExpectedQueryString("UPDATE objecttable set ...");
  dbUtility.update(mockConnection, new SQLObject[] { obj2 });
  mockStatement.verify();

  ... etc. ...
}

this is better, although now i'm not testing my ability to do all three at
once.

but now i decide to change my implementation of update() so that instead of
calling executeUpdate() on a Statement, it gets a ResultSet, and goes
through it updating and deleting and inserting rows as appropriate.

oops.  my tests just broke.

i'm not sure what to think about this.  since there is always more than one
way to do an update in JDBC, it seems to follow that there is no
implementation-INdependent way to test a method which is supposed to perform
some set of JDBC updates depending on the state of something-or-other, if
the only tools you have are tools that test which particular JDBC methods or
SQL queries you performed.

i don't see the point of writing implementation-dependent tests.  i want to
test the input-output behavior of my methods, not how they function.

comments?

-brian