Fwd: Re: [MO-java-dev] Avoiding loops in Verifier again.

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

Whoops.. Wrong reply mode...

=2D---------  Forwarded Message  ----------

Subject: Re: [MO-java-dev] Avoiding loops in Verifier again.
Date: Monday 07 October 2002 10:14
=46rom: Simon Levitt <sim...@uk...>
To: "Steve Freeman" <st...@m3...>

On Thursday 03 October 2002 12:30, Steve Freeman wrote:
> > The aim of MockObjects, surely?, is to support anything that can be
> > thrown at it. Isn't just ignoring this kind of 'problem' limiting?
> > The MockObjects must be as complicated as the thing they are trying
> > to Mock. Ignoring parts of industry standard interfaces sounds like a
> > death sentence to me...
>
> Not exactly. We also use complexity in testing as a hint that our
> design might be getting out of hand. For example, what kind of code
> would get a statement from a connection, and then the connection from
> the statement, in the same fragment? Sounds like there are two pieces
> there that could be tested seperately.

That's fair enough. I've actually never used getConnection on a Statement
object!.

> In that case, you should have different mock clusters set up for each
> piece and there should be no recursion. The problem then becomes one of
> making test setup  lightweight and easy, rather than making the mock
> complete.

Now whilst I can see this being a nice ideal (and easily implemented for
domain specific classes), I can also see the number of these clusters
becoming completely unmanageable - both from the point of view of
maintenance and upgrade of the Mocks themselves, but finding which
cluster to use when writing test cases.

With JDBC being such a generic mechanism the way it will be used will
 vary considerably from one developer to another. If the whole interface
 can be implemented relatively simply in one Mock - why not do it.

My changes to the JDBC classes implement as much of the interface as the
originals (in some cases more, and follows the specification better in a
couple of places), and I don't think they're really any more complicated
than the originals (In fact I believe I've cleaned the hierachy of common
and JDK specific objects up - making it more consistant with the other
JDBC objects).

> We need to find ways for people to do everything they need to, but that
> doesn't mean that we need a single mock implementation for all possible
> tests.

I think in a lot of cases, particularly the more generic interfaces, that
is going to be orders of magnitude easier to say than do.

> Increasingly, I find myself creating a null implementation of an
> interface and then overriding the methods I need for a particular test
> in an anonymous class.

That's a nice idea, but I can only see that working for domain specific
objects. Testers can't be expected to roll their own ResultSet object for
example.

> One of the essential points about testing with
> mocks is that the mocks must be simple enough that the failures will
> always be in the target code and that this should be obvious. Our mock
> implementations are now getting to the point where they need tests
> themselves and that bothers me.

But surely the MockObjects need to be providing a conformant interface
 for what they are trying to mock, and testing that expectation of that
 interface given a specifc set of mock data can't be a completely bad
 thing. eg. testing that all the variation methods for setting row data
 on a ResultSet actually results in the Mock behaving the same.

Some mocks are going to have to have some logic to determine what to
return when, and it can't be a bad idea to test that.

> Easy now, in a moment one of us will use the N?zi word and the game
> will be over ;-)

*8-)

> > Also in certain cirumstances Verifier can be involved in mantaining
> > the infinate loops and inherant stack overflow that occurs in these
> > circumstances, is this the sort of image a project that should be
> > capable of being used in the commerce commercial quality projects be
> > projecting?
>
> Don't understand this.

Sorry, thats one of those sentences I re-wrote about 4 times, and then
obviously read what I thought was there...

Basically: If the Verifier is allowed to cause or participate in the
verification of an Object that causes a stack overflow then its going to
look bad on the Verifier (whether it was core MockObjects objects that
caused it, or test specific mocks).

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/ -----------------------