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

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

From: "Simon Levitt" <sim...@uk...>
> On Sunday 29 September 2002 17:58, Steve Freeman wrote:
> > I'd like to propose that a Verifiable loop is a code smell which
> > implies that something has become too complicated, so we shouldn't
> > compensate for it.
> >
> > Thoughts?
> >
> As I introduced the code that tried to cope with smell (in a simple way -
> through the static Vector) I suppose I should comment.
>
> I think you may be over generalising here in that MockObjects currently
> only has one place where a child requires a reference to its parent
> (which has a reference to its children), and you're trying to avoid the
> potential problem by defining it as a smell.
>
> 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. 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.

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

Hmmm. Perhaps we should be gathering patterns of use for each library and
writing some canned setups for each one?

> Having ideals is fine, sticking them to the end without compromise is
quite often stupid.

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

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

> As far as the JDBC problem goes could it be gotten around by storing the
> parent references as the implemented interface rather than the Mock
> reference?

True, or a simple null stub. Depends on what the test needs.

Steve