Re: Revert use_ok() change to allow lexical effects?

2012-04-12 Thread Eirik Berg Hanssen 
On Wed, Apr 11, 2012 at 6:32 PM, Michael G Schwern wrote:

> 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;
>

*cut*

  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 run, burying
the interesting output.  More uninteresting output.

  Which are two very annoying changes in your rewrite.  And of course,
there's more of the same in the part of the rewrite I cut.




> * Why would you? :-\
>
> Because it reads like normal Perl and doesn't rely on more code to do
> something rather simple: load a module.
>

  But it fails to DWIW: report clearly on failures.  Perhaps what it is
doing is not so simple, after all?



> But quite honestly, if use_ok() works for you, if all you need is require +
> import + test, continue to use it.  I don't plan on eliminating it.
>

  Thank you.


Eirik

Re: Revert use_ok() change to allow lexical effects?

2012-04-12 Thread Michael G Schwern 
On 2012.4.11 1:45 PM, Andy Lester wrote:
> test_requires is Module::Build only, right?  I don't use Module::Build.

It was just added to ExtUtils::MakeMaker but I don't know when a stable will
be released.


-- 
There will be snacks.

Re: Revert use_ok() change to allow lexical effects?

2012-04-12 Thread Michael G Schwern 
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 potentially interfere with
>> or be overwritten by the code being tested.
> 
> … what for? Is Ovid’s solution of just using an END block insufficient?
> Why?

You're referring to this?
http://www.nntp.perl.org/group/perl.qa/2012/04/msg13128.html

If all you want is to bail out if the test fails to complete, that's easy(er).
 I thought it was going to do something specifically when a `use` fails, thus
all the complexity.

A general "bail out if this test file fails" function might be handy.  An even
more general "do X if the test finishes in Y state" would be even more handy.

# There is no test_passed()
END { BAIL_OUT() unless test_passed(); }

I don't want to add a huge bunch of functions to Test::More to cover all the
possible test states, in 1.5 you can get them from the TB2::History object.

# This works in TB 1.5
END { BAIL_OUT() unless Test::More->builder->history->test_was_successful }

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 }


-- 
Look at me talking when there's science to do.
When I look out there it makes me glad I'm not you.
I've experiments to be run.
There is research to be done
On the people who are still alive.
-- Jonathan Coulton, "Still Alive"