On 2012.4.14 4:03 AM, Aristotle Pagaltzis wrote:
Which is a bit of a mouthful. Providing a function to get at the
history object would make a bunch of test state introspection easier.
# That looks pretty good.
END { BAIL_OUT() unless test_history-test_was_successful }
I like that.
On Wed, Apr 11, 2012 at 6:32 PM, Michael G Schwern schw...@pobox.comwrote:
On 2012.4.10 6:21 PM, The Sidhekin wrote:
* How would you rewrite a test script such as my own
http://cpansearch.perl.org/src/EBHANSSEN/Test-Trap-v0.2.2/t/00-load.t so
that it does not use use_ok()?
use
On 2012.4.11 1:01 PM, Aristotle Pagaltzis wrote:
Unless I'm mistaken, Test::AutoBailOut is doing to need a global
$SIG{__DIE__} handler or override CORE::require or add something to
@INC or try to parse exception messages or something like that. Any
of those have global side effects which can
On Wed, Apr 11, 2012 at 2:30 AM, Aristotle Pagaltzis pagalt...@gmx.dewrote:
* Mike Doherty dohe...@cs.dal.ca [2012-04-11 01:10]:
I typically use_ok(...) or BAIL_OUT. If that's the only way to use
use_ok safely, then maybe it should do that for you automatically.
I don’t think changing its
- Original Message -
From: The Sidhekin sidhe...@allverden.no
* How would you rewrite a test script such as my own
http://cpansearch.perl.org/src/EBHANSSEN/Test-Trap-v0.2.2/t/00-load.t so
that it does not use use_ok()?
* Why would you? :-\
Just a quick hack:
use Test::More;
: Wednesday, 11 April 2012, 16:22
Subject: Re: Revert use_ok() change to allow lexical effects?
- Original Message -
From: The Sidhekin sidhe...@allverden.no
* How would you rewrite a test script such as my own
http://cpansearch.perl.org/src/EBHANSSEN/Test-Trap-v0.2.2/t/00
On 2012-04-11, at 16:22, Ovid wrote:
eval use $module;
BAIL_OUT $@ if $@;
Alternatively:
eval use $module; 1
or BAIL_OUT ( $@ // 'zombie error' );
--
Ruud
So is there ANY legit use for use_ok()?
xoa
--
Andy Lester = a...@petdance.com = www.petdance.com = AIM:petdance
Aristotle Pagaltzis writes:
Ah d’uh! Now I feel stupid.
Please don't! You're still ahead many of us ...
This could so easily be packaged in a handful of lines:
Thanks for doing that.
my $reason = 'Tests must succeeded';
Grammar correction if anybody is going to publish this in a
On 2012.4.10 2:52 PM, Mike Doherty wrote:
On 12-04-10 05:20 PM, Paul Johnson wrote:
On Tue, Apr 10, 2012 at 12:20:20PM -0700, Michael G Schwern wrote:
2. Should use_ok() be discouraged in the documentation?
I'm very much in favour of this.
I don't see any discouragement in the
On 2012.4.10 6:21 PM, The Sidhekin wrote:
* How would you rewrite a test script such as my own
http://cpansearch.perl.org/src/EBHANSSEN/Test-Trap-v0.2.2/t/00-load.t so
that it does not use use_ok()?
use Test::More tests = 1;
use Test::Trap::Builder::TempFile;
use
On 2012.4.11 7:35 AM, Andy Lester wrote:
So is there ANY legit use for use_ok()?
Yes. Sometimes you want to conditionally test if a module can be loaded and
its import does not blow up.
It's a convenience function so it can be more easily understood what's going
on and we don't each write it a
On Apr 11, 2012, at 11:33 AM, Michael G Schwern wrote:
It's a convenience function so it can be more easily understood what's going
on and we don't each write it a million different ways. require_ok() solves a
big chunk of the problem.
if( something something ) {
use_ok 'Foo';
On Wednesday, April 11, 2012 at 09:39 AM, Andy Lester wrote:
In this example:
BEGIN {
use_ok( 'App::Ack' );
use_ok( 'App::Ack::Repository' );
use_ok( 'App::Ack::Resource' );
use_ok( 'File::Next' );
}
diag( Testing App::Ack $App::Ack::VERSION, File::Next
* Michael G Schwern schw...@pobox.com [2012-04-11 18:35]:
Nope, too much magic for too small a use case.
And faithfully duplicating `use` would be less so? :-)
I don’t see how it is any more magic than `done_testing`.
What exactly makes you uneasy? Maybe there is a way to address that
if you
- Original Message -
From: Aristotle Pagaltzis pagalt...@gmx.de
* Michael G Schwern schw...@pobox.com [2012-04-11 18:35]:
Nope, too much magic for too small a use case.
And faithfully duplicating `use` would be less so? :-)
I don’t see how it is any more magic than
* Ovid publiustemp-perl...@yahoo.com [2012-04-11 19:10]:
* Aristotle Pagaltzis pagalt...@gmx.de [2012-04-11 18:55]:
I don’t see how it is any more magic than `done_testing`.
Because done_testing is applicable to every test module and solves the
far more common issue of hating maintain a
On 2012.4.11 9:39 AM, Andy Lester wrote:
In this example:
BEGIN {
use_ok( 'App::Ack' );
use_ok( 'App::Ack::Repository' );
use_ok( 'App::Ack::Resource' );
use_ok( 'File::Next' );
}
diag( Testing App::Ack $App::Ack::VERSION, File::Next $File::Next::VERSION,
Perl $], $^X
* Smylers smyl...@stripey.com [2012-04-11 18:20]:
Aristotle Pagaltzis writes:
my $reason = 'Tests must succeeded';
Grammar correction if anybody is going to publish this in a module:
succeed, rather than succeeded.
Woops. Thanks.
Ah d’uh! Now I feel stupid.
Please don't! You're
On 2012.4.11 9:53 AM, Aristotle Pagaltzis wrote:
* Michael G Schwern schw...@pobox.com [2012-04-11 18:35]:
Nope, too much magic for too small a use case.
And faithfully duplicating `use` would be less so? :-)
This discussion is about backing away from that. The most magical bits of
use_ok()
On 2012.4.11 11:43 AM, Eirik Berg Hanssen wrote:
If this fails, the test script will terminate immediately:
* I won't get to know if any of the other modules loaded correctly, or how
they fail. Less of the interesting output.
* And there will be no BAIL_OUT, so the rest of the tests will
- Original Message -
From: Michael G Schwern schw...@pobox.com
But it fails to DWIW: report clearly on failures. Perhaps what it is
doing
is not so simple, after all?
Personally I'm a fan of scroll up and read the first failure.
It always works!
Try it on a Test::Class
* Michael G Schwern schw...@pobox.com [2012-04-11 20:10]:
On 2012.4.11 9:53 AM, Aristotle Pagaltzis wrote:
I don’t see how it is any more magic than `done_testing`.
done_testing() has no global side effects, it's just a function.
Unless I'm mistaken, Test::AutoBailOut is doing to need a
* Ovid publiustemp-perl...@yahoo.com [2012-04-11 21:55]:
From: Michael G Schwern schw...@pobox.com
Personally I'm a fan of scroll up and read the first failure. It
always works!
Try it on a Test::Class test suite running thousands of test in
a single process, whizzing past on your terminal
Btw Ovid,
* Ovid publiustemp-perl...@yahoo.com [2012-04-11 19:10]:
done_testing is applicable to every test module and solves the far
more common issue of hating maintain a plan.
^^
a little Freudian slip there? :-)
On Apr 11, 2012, at 3:01 PM, Aristotle Pagaltzis wrote:
OK. Then how about I stick AutoBailout on CPAN with a SYNOPSIS that
covers `t/00-load.t`, and then you change the `use_ok` docs to a)
discourage its use and b) point to AutoBailout for `t/00-load.t` uses.
Sound good?
As a module
On 04/11/2012 04:29 PM, Andy Lester wrote:
As a module author, I would not require a user to install AutoBailout.pm just
to remove boilerplate in my t/00-load.t
With the test_requires stuff they won't have to. It will only be used
for testing and not installed permanently on their system.
* Andy Lester a...@petdance.com [2012-04-11 22:30]:
As a module author, I would not require a user to install
AutoBailout.pm just to remove boilerplate in my t/00-load.t
If it’s only a test_requires the user won’t have to. (It would be pretty
silly to keep discarding it though if it gets
On Apr 11, 2012, at 3:38 PM, Michael Peters wrote:
As a module author, I would not require a user to install AutoBailout.pm
just to remove boilerplate in my t/00-load.t
With the test_requires stuff they won't have to. It will only be used for
testing and not installed permanently on
On 04/11/2012 04:45 PM, Andy Lester wrote:
test_requires is Module::Build only, right? I don't use Module::Build.
No, I'm pretty sure it works with Module::Install and
ExtUtils::MakeMaker now too. Although that might just be something that
was worked on at the qa-hackathon.
Even if I
* Michael Peters mpet...@plusthree.com [2012-04-11 23:15]:
On 04/11/2012 04:45 PM, Andy Lester wrote:
test_requires is Module::Build only, right? I don't use
Module::Build.
No, I'm pretty sure it works with Module::Install and
ExtUtils::MakeMaker now too. Although that might just be
On Apr 11, 2012, at 5:48 PM, Aristotle Pagaltzis wrote:
The stop energy
he is throwing at it has no substantive reason so far, only “I don’t
care for this”.
No, no, no, I'm sorry, I didn't mean to make it sound like You shouldn't do
this module. No stop energy intended. I just wanted to
On 4/11/12 12:33 PM, Michael G Schwern wrote:
Let me reiterate, I have no plans to *deprecate* `use_ok`. Even if I wanted
to there are simply too many users to make deprecation worth while.
It works fine if what you want is a runtime require + import + assert, and
sometimes you want that.
In a series of patches, Father Chrysostomos and I enhanced use_ok() so that it
can apply lexical effects to more closely emulate the real `use`. For example,
use_ok('strict');
Previously this would just load strict and call import, but strictures would
not actually be applied to your scope.
On 12-04-10 05:20 PM, Paul Johnson wrote:
On Tue, Apr 10, 2012 at 12:20:20PM -0700, Michael G Schwern wrote:
2. Should use_ok() be discouraged in the documentation?
I'm very much in favour of this.
I don't see any discouragement in the documentation... and what's wrong
with use_ok to begin
On Apr 10, 2012, at 4:59 PM, Leon Timmermans wrote:
If it fails, the module may not be loaded, or partially loaded. In
such circumstances, testing the rest of the code can give very
confusing results. It doesn't make sense to continue testing usually.
It seems that use_ok() ought to die if
On 12-04-10 05:59 PM, Leon Timmermans wrote:
On Tue, Apr 10, 2012 at 11:52 PM, Mike Doherty dohe...@cs.dal.ca wrote:
I don't see any discouragement in the documentation... and what's wrong
with use_ok to begin with?
If it fails, the module may not be loaded, or partially loaded. In
such
37 matches
Mail list logo
