[Israel.pm] Testing problem

Mikhael Goikhman migo at homemail.com
Tue Jan 6 04:13:09 PST 2004


On 06 Jan 2004 13:30:46 +0200, Shlomi Fish wrote:
> 
> On Tuesday 06 January 2004 10:41, Mikhael Goikhman wrote:
> > On 06 Jan 2004 09:44:05 +0200, Shlomi Fish wrote:
> > > On Tuesday 06 January 2004 06:43, Ran Eilam wrote:
> > > > 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.
> >
> > There is no doubt the OO way rules, but I am not sure whether you
> >
> > suggested any usable solution. You wrote:
> > > What I would do is this:
> > >
> > > sub myopen
> > > {
> > >         my ($self, at param) = @_;
> > >         $pid = open $fh, "-|", "command @param";
> > >         return ($pid, $fh);
> > > }
> > >
> > > sub method
> > > {
> > >         my ($self, at param) = @_;
> > >         ($pid, $fh) = $self->myopen(@param);
> > >         # Rest of method
> > > }
> > >
> > > And then in the test override myopen with a mock function.
> >
> > It is not clear from this, how exactly can you "override myopen with a
> > mock function" so that it still returns a valid pid and a file handler.
> 
> So I guess you need to mock things all the way. Pass around a tied
> filehandle, and also use some wrappers (or mocked built-in functions)
> for the PID.

And all this new non-trivial code (that should be tested too) just to
emulate `cat file` that you know works without bugs.

Maybe on the meeting we will have some minutes to speak about when it is
worth to create new classes just for testing, when new wrappers, and when
just to add "if $ENV{DEBUG}" lines to the code.

Regards,
Mikhael.

-- 
perl -e 'print+chr(64+hex)for+split//,d9b815c07f9b8d1e'



More information about the Perl mailing list