[Israel.pm] Testing problem

Ran Eilam eilara at cortext.co.il
Sun Jan 11 14:41:42 PST 2004

Thomas Maier wrote:

> Ishay Inbar write:
> > In the bottom line the only reliable way to test properly
> > is to execute in real life scenarios as much as possible.

> Correct. Just consider the follow scenarios:
>  1. test target (your real life scenario) still does
>     not exists.
>  2. test target is full of bugs.
>  3. test target works extremely slow.

I especially use #1. Mocking is a great way to test your objects before
their collaborators are written. Sometimes it is the only way if you are
doing TDD.

I have never thought of #2. Very funny that such subsystems can reach
'Quality' assurance stage! ;)

And there are other reasons:


And there are other reasons:

1. sometimes testing costs money, like with prepress systems, where each
page print costs a few cents. You cannot in such cases print a page for
too many unit tests.

2. They make it easier to increase coverage. Thomas wants to (perhaps)
test what happens when the write fails, when the file is empty, etc. Not
just the path he talked about in the mailing list. But these paths could
be difficult to setup. So you want to minimize the price per fixture.
Mock objects help.

Anyways I guess Ishay is focusing on acceptance tests, where mocking is
problematic. Perhaps even directly opposing the central dogma of
acceptance testing.

Thomas once told me that product integration tests, like he is doing,
are complex enough to warrant unit testing themselves.

Both Jason and Ishay seem to think mocking is very difficult. True, but
this is a diminishing cost. Once your team knows mocking tricks and has
a good mocking framework, the cost goes down dramatically.

There exist, for example, recording mocks. These allow you 1st to record
expected calls on collaborators, and then replay them to verify that the
exact sequence you recorded was played by the UIT. This makes it even
easier to setup up your mock fixture.


More information about the Perl mailing list