[Israel.pm] Testing problem

Ran Eilam eilara at cortext.co.il
Mon Jan 5 20:43:54 PST 2004


> Shlomif said:
> What I would do is this:
> ...
> And then in the test override myopen with a mock function.

When you cannot do the unix tango as migo suggested, OO tricks like
shlomi proposed are best.

For a small catalog of patterns for mock objects:

http://jerry.cs.uiuc.edu/~plop/plop2003/Papers/Brown-mock-objects.pdf

Shlomi's trick would be a variant of Mock Object via Factory using
subclassing, and the Pass in Mock Collaborator solution was mentioned
earlier in the thread.

With the advent of Aspect Oriented Programming, mocking is MUCH easier,
and is done through method call interception. So you would just trap the
call to open(), verify that it got the expected parameters, and return
success of failure depending on what you are testing. No need to spawn
any programs we are not supposed to be testing.

No need for hackery: unix OR OO.

Of course Perl is so dynamic you don't really need any AOP tools. Just
mock *CORE::GLOBAL::open, and replace it back again when the test is
done. This is exactly how the MockTime example worked. I showed it to
the group in one of our meetings. I think there were a few people there,
and they were supposed to be listening...

Unless I am mistaken, it is the same general problem: mocking Perl
builtins.

Could be a problem if your test does several open(), but you only want
to mock one. Probably rare.

	Ran



More information about the Perl mailing list