On Tue, 2004-05-25 at 06:58, Francisco Olarte Sanz wrote:
I've been looking at the documentation for the test modules (Test::More,
Test::Simple, Test::Builder ), and I've found nothing regarding the return
value of the ok(), is(), etc... functions/methods. Browsing through the
source
On Tue, May 25, 2004 at 09:16:51AM -0700, chromatic ([EMAIL PROTECTED]) wrote:
On Tue, 2004-05-25 at 06:58, Francisco Olarte Sanz wrote:
It's a reliable feature. If it's not documented, it should be.
It should also be stated so that folks who use Test::Builder know to
make their functions
Many times in test suites I don't want to mock up an entire class or package.
Instead, there are
only one or two target subroutines that I want to change. I get awfully tired of
doing the
following, though:
{
no warnings 'redefine';
my $message;
local *Foo::bar = sub { $message
On 25 May 2004, at 18:31, Ovid wrote:
[snip]
So I wrote a little module, Sub::Override, to do that for me. I can
replace subs, explicitly
restore them to their original value or just let the object fall out
of scope and have the subs
automatically restored. However, this seems like such an
* Francisco Olarte Sanz. [EMAIL PROTECTED] [2004-05-25T13:58:21]
? Which aproach is better, have a single independent huge test file or
several interdependent smaller ones ( w/ notes in the readme stating
test dependence ) ?
The better approach is the one that makes it most likely for you to
On Tue, May 25, 2004 at 07:58:21PM +0200, Francisco Olarte Sanz. wrote:
1st of all, thanks everyone for the prompt response regarding my
previous question about return values.
Now a style question. I'm doing a database oriented module, and I have
rouhly the following tests:
1.- Test
--- Adrian Howard [EMAIL PROTECTED] wrote:
Hook::Lexwrap?
It's what I normally use for this sort of thing, and you can
short-circuit the original method in a pre- wrapper.
Ah, never knew about the short-circuiting. Thanks!
Cheers,
Ovid
=
Silence is Evil
Francisco,
Personally I like to have tests that depend upon one another in a
single file. However, that is not always possible or easy to do. In
your case though, I would suggest you use mock objects for your
database instead of a real database. This would allow your tests to be
run
