Re: [MO-java-dev] verify()ing object hierachies.

[Simon L. <sim...@uk...>]

On Sunday 20 October 2002 16:45, Steve Freeman wrote:
> It struck me that we're not really converging on this topic, partly
> because we don't have enough time but mainly because we're not really
> working against the same problems.=20
[...]
>
Unfortunately, other than the obvious getting a Connection from a=20
Statement issue we've highlighted before I haven't come across an other=20
real examples. I've really been talking in the abstract, and how=20
MockObjects could perhaps be used outside of the ideal use only in new=20
projects written with them in mind.

> You post a (made-up) example of a case that you want to unit-test and
> that you think needs a change. We'll respond and see if we can find a
> meaningful way around it. If not, then you win the point.
>
The trouble is any example I come up with quickly (and unfortunately I=20
haven't got the time to do anything else), is probably going to be easily=20
picked apart by saying that it shouldn't be written that way.

StrawMan:

public class DataObject
{
	private static Statment stmt =3D 		=09
			Global.getConnection().createStatement();

	public DataObject(String name, int flags, boolean readOnlyRecord)
	{
		...
	}
=09
	...

	public static DataObject load(String id)
	{
		try {
			result =3D stmt.executeQuery("SELECT * FROM table WHERE id =3D " + id);
			if (result.next()) {
				obj =3D new DataObject(result.getString(1), result.getInt(3),
							       stmt.getConnection().isReadOnly());
			}
		}
		catch (SQLException e) {
			throw DataObjectException(e.toString());
		}
		return obj;
	}
}

You can test the object outside of the scope of the database, but the=20
database functionality is fully encapsulated in the Object itself. The=20
point of use of the load() method doesn't even need to know that the=20
database is being used. It also isn't storing and object for the sake of=20
testing (ie. the implementation knows that a statment is associated with=20
a particular connection, therefore doesn't need to store the Connection).

With the com.mockobjects.sql package as it stands (or did last time I did=20
an update) setting up this situation will cause a StackOverflowError (if=20
verify is called on the Connection.

This failure is partly due to the way the sql MockObjects have been=20
written, but its the verifier that actually causes the fatal error on=20
tests.

I believe the verifier should be able to detect this situation (probably=20
warning about it) and cope in a far better way. Similar situations could=20
easily be created in user developed MockObjects, if any similar hierachy=20
is created, and informing them is IMO far better than crashing.

> I figure that this will be a reasonably lightweight mechanism for
> understanding each other and for pushing the dialogue along. One case
> at a time...
>
This is probably the biggest difference, I'm not looking at a specific=20
single case, I'm thinking more generally.

This is a very small point, far eclipsed by the discussions we've had.

Whilst I think its important, more from a perception of MockObjects point=20
of view I don't much care if its taken on board any more. Particularly as=20
we appear to be the only two concerned about it in any form.

I'd much rather be spending time presenting the rationisation I've done=20
for the sql objects in general in preparation for the PreparedStatement=20
work I was going to do - which I suspect treads on your beliefs of single=20
situation Mocks and no test cases (as it uses the same implementation of=20
ResultSet for multi and single row results, and has test cases to ensure=20
the various combinations of build methods give the same results).

Simon.,
=2D-=20
=2D-------------------------------------------------------------------------
         Simon Levitt, Senior Development Engineer @ WorldPay plc,
WorldPay Centre, The Science Park, Milton Rd., Cambridge, CB4 0WE, ENGLAND =
=20
 Sim...@uk...   Ph:+44(0)1223 715151  F:+44(0)1223 715157
=2D------------------------ http://www.worldpay.com/ -----------------------