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