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

[Steve F. <st...@m3...>]

Looking at this, one solution is not to use a Verifiable for the connection.
You need a stub here, more than a mock and you're not really testing
anything about how the connection behaves. You can knock up a stub
implementation very quickly using anonymous classes in front of a null
implementation. Alternatively, you could relax the access on the static
statement and set it during the test. Alternatively, you could get more
sophisticated and use AspectJ to intercept the call.

From: "Simon Levitt" <sim...@uk...>
> StrawMan:
>
> public class DataObject
> {
> private static Statment stmt =  Global.getConnection().createStatement();
>
> public DataObject(String name, int flags, boolean readOnlyRecord)
> {
>
> public static DataObject load(String id)
> {
> try {
> result = stmt.executeQuery("SELECT * FROM table WHERE id = " + id);
> if (result.next()) {
> obj = new DataObject(result.getString(1), result.getInt(3),
>        stmt.getConnection().isReadOnly());
> [...]
>
> > 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
> single case, I'm thinking more generally.

I was just trying to find a way to get there gradually, rather than in one
go.

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

I'm not sure that's completely true. There are quite a few lurkers.

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

Well, I'm beginning to soften on No Test Cases, simply because I can't
remember what everything does any more. That said, Nat Pryce and I have been
doing some interesting work with dynamic proxies that might make some of the
issues go away. I don't know if we'll ever achieve a complete implementation
of the standard, so maybe we should try to go around the problem. Hmmm. I'll
take another look at your previous proposal.

S.