You don’t have to use objects to get the same end effects as mocking objects.
Mocking is a technique for OO code to achieve the following aim -
"the code under test should not be changed to test it"
The code _should_ (I'd prefer _must_ but lets not get into absolutes just yet)
NOT be aware its under test. There are a number of ways to do this.
If the code under test uses a Mail object of some kind, creating a mock object
for it to use is pretty simple.
If the code under test makes a function call to a module (in Perl-world) or a
library (in C/C++-world), you should provide a test library for it to call,
that has exactly the same API as the production library, plus extra functions
to setup what it does when the API is used. For example, say the Mail API has a
send() function. You code under test calls 'send(some args)' at some point. The
test harness calls the test libraries 'setup_send()' function to do lots of
interesting things at various times - pretend the mail went out ok, pretend the
mail bounced, pretend lots of stuff. In the perl world, (recommended) use the
Mock:: modules from CPAN. Or (not recommended) the real Mail module could be
.../Prod/Mail.pm, and the test version could be ../Test/Mail.pm, and you get to
play stupid PERL5PATH games. Or In C/C++, you can change the LD_LIBRARY_PATH
for linking the real or test versions.
If your code under test makes a system() call to send mail, you get to play
path tricks again so that a dummy mail program is called instead of the real
one. This may mean you have to chroot() to an env where everything is fake.
I think code under test that has "if I'm under test" statements is
intrinsically weak. You want to test "what it does", not "what it does when
under test". Changing the code for testing means your not really testing it ,
your testing a variation of it.
Leif
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Friday, 12 January 2007 11:04 AM
To: perl-qa@perl.org
Subject: Re: Test::Builder feature request
Nadim Khemir writes:
> On Thursday 11 January 2007 18:04, Ovid wrote:
>
> > > Just one, Shouldn't the mailer "object" be mocked and the mail
> > > sending checked?
>
> > absolutely, but how do you know to mock it or really send the email
> > unless you know that you're being run by tests?
>
> Aren't you mixin contexts here? The code to be checked is sending mail
> (right?). The test framework mocks the mail object so only the test
> code needs to do something special and I believe the test code knows
> the test code is running.
You're assuming that the mail-sending code is an object, and separate from
other things that should be run in the test. In bad code (which Ovid stated
this is) those aren't reasonable assumptions to make!
> > ... when one is working with ugly code, sometimes it can be very
> > difficult to refactor complicated bits out so that they can be
> > easily overridden by tests
>
> Yeah, you have a bunch of ugly code and the best way is to make it
> even more ugly by making it aware of the testing.
Sometimes. At least in the short term.
> I've never seen any requirement that says: "when testing, don't do
> this and that".
Me neither. But I've seen lots of requirements that don't make any mention of
testing at all. And lots of code that doesn't even have any requirements about
anything.
But suppose some code does a bunch of processing and then finally interacts
with the outside world in some way (sending an e-mail, completing a financial
transaction, controllig a robot) during testing it may be readily apparent that
it would be disruptive to have that action occur.
> I'm actually wondering if code which has knowledge of it being tested
> is testable at all! well ' it's not. because you can never test the
> "send mail" feature.
Sure. But you can at least test everything else, all the processing up to the
point which sends the mail. And you could in the test environment put the data
that would be in the mail somewhere else, which can be tested, so that just
leaves the actual mail transport being untested -- and that's probably being
done with a Cpan module or something which has been tested elsewhere.
> I'm sure you're not inventing this but one actually made the code
> worse whith that kind of hack. IMHO, just enabling this kind of code
> is going against everything you want to achive, testable applications.
No, it's enabling you to test other code that is near an action which
absolutely cannot be run in a test environment, thereby making more of the
application testable.
Smylers
--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.410 / Virus Database: 268.16.9/622 - Release Date: 10/01/2007
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.410 / Virus Database: 268.16.9/622 - Release Date: 10/01/2007
**********************************************************************
IMPORTANT
The contents of this e-mail and its attachments are confidential and intended
solely for the use of the individual or entity to whom they are addressed. If
you received this e-mail in error, please notify the HPA Postmaster, [EMAIL
PROTECTED],
then delete the e-mail.
This footnote also confirms that this e-mail message has been swept for the
presence of computer viruses by Ironport. Before opening or using any
attachments, check them for viruses and defects.
Our liability is limited to resupplying any affected attachments.
HPA collects personal information to provide and market our services. For more
information about use, disclosure and access see our Privacy Policy at
www.hpa.com.au
**********************************************************************
