[Israel.pm] Testing problem

Shlomi Fish shlomif at iglu.org.il
Mon Jan 5 23:44:05 PST 2004

On Tuesday 06 January 2004 06:43, Ran Eilam wrote:
> > 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

Thanks! I'll take a look.

> Shlomi's trick would be a variant of Mock Object via Factory using
> subclassing, 

Whew! A long name, to say the least. Albeit I read the Design Patterns book, I 
must say that sometimes this pattern craze is a bit annoying. If you're using 
a technique in the code, it is a good idea to explain it using plain English, 
instead of using some obscure pattern name.

For instance, the "geometry manager pattern" can simply be a "geometry 
manager" or a "layout manager", which existed a long time before the gang of 
four book was written.

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

I was listening. ;-) I just did not thought about it in regards to Thomas' 
example, and the refactoring and subclassing solution seemed more modular.

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

Which is one reason I think why my solution is better.


	Shlomi Fish


Shlomi Fish      shlomif at iglu.org.il
Homepage: http://t2.technion.ac.il/~shlomif/

I don't believe in fairies. Oops! A fairy died.
I don't believe in fairies. Oops! Another fairy died.

More information about the Perl mailing list