Guys,
> Looking at this a different way, instead of a library, make a distzilla
> extension (or whatever) which generates (and regenerates) a 00-load.t
> as per Ovid's earlier example.
> :
> :
This sounds like the best idea to me.
-- Buddy
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. The
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 t
* Michael Peters [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 something
> that was w
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 did,
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 o
* Andy Lester [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 widespread use, esp se
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.
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 au
Btw Ovid,
* Ovid [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? :-)
* Ovid [2012-04-11 21:55]:
> >From: Michael G Schwern
> >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 :)
That is not relevant to t/00-lo
* Michael G Schwern [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 global
> $SIG{_
- Original Message -
> From: Michael G Schwern
>> 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 test s
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 w
# from Michael G Schwern
# on Wednesday 11 April 2012 11:06:
>> What exactly makes you uneasy? Maybe there is a way to address that
>> if you can be more specific.
>
>Mostly that it's cramming yet more complexity into core test library
> for a fairly narrow use case and functionality that lives qu
On 2012.4.11 9:53 AM, Aristotle Pagaltzis wrote:
> * Michael G Schwern [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() have not yet
* Smylers [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 still ahe
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
* Ovid [2012-04-11 19:10]:
> * Aristotle Pagaltzis [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 plan. I would argue that
> done_testing is m
- Original Message -
> From: Aristotle Pagaltzis
>
> * Michael G Schwern [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`.
Because done_testin
* Michael G Schwern [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 can be more specif
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 $File::N
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 'F
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 2012.4.11 8:45 AM, Aristotle Pagaltzis wrote:
> Then you simply do this:
>
> use Test::More tests => 1;
> use Test::AutoBailOut reason => 'Could not load prerequisites';
> use Config;
>
> use Test::Trap::Builder::TempFile;
> use Test::Trap::Builder::SystemSafe;
> use Te
> --
> ROCKS FALL! EVERYONE DIES!
> http://www.somethingpositive.net/sp05032002.shtml
>
I think we've found our correct non-loading module behavior right there.
xoa
--
Andy Lester => a...@petdance.com => www.petdance.com => AIM:petdance
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 Test::Trap::Builder:
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 d
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 mod
* Ovid [2012-04-11 16:35]:
> my $ok;
> END { BAIL_OUT "Could not load all modules" unless $ok }
[...]
> ok 1, 'All modules loaded successfully';
> $ok = 1;
Ah d’uh! Now I feel stupid.
This could so easily be packaged in a handful of lines:
package Test::AutoBailOut;
On Wed, Apr 11, 2012 at 4:22 PM, Ovid wrote:
> my @modules = qw(
> Test::Trap::Builder::TempFile
> Test::Trap::Builder::SystemSafe
> Test::Trap::Builder
> Test::Trap
> );
> push @modules => 'Test::Trap::Builder::PerlIO' if eval "use P
So is there ANY legit use for use_ok()?
xoa
--
Andy Lester => a...@petdance.com => www.petdance.com => AIM:petdance
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
Or more simply:
use Test::More tests => 1;
my $ok;
END { BAIL_OUT "Could not load all modules" unless $ok }
use Test::Trap::Builder::TempFile;
use Test::Trap::Builder::
- Original Message -
> From: The Sidhekin
> * 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;
On Wed, Apr 11, 2012 at 2:30 AM, Aristotle Pagaltzis wrote:
> * Mike Doherty [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 meaning so drastically is f
36 matches
Mail list logo