Re: Failures in pre-requisites

* David Cantrell <[EMAIL PROTECTED]> [2007-08-03T16:21:44] > David Golden thought that this might be more useful as a web thing than > done by email by the CPAN testers, so I hacked something up: > http://cpandeps.cantrell.org.uk/ That's pretty cool, even if it is a foul, disgusting hack. -- r

Re: Failures in pre-requisites

David Cantrell wrote: > David Golden thought that this might be more useful as a web thing than > done by email by the CPAN testers, so I hacked something up: > http://cpandeps.cantrell.org.uk/ > > It's a foul, disgusting hack. If anyone wants to make it less sucky (eg > to work off local datab

Re: Tests involving regexes

demerphq wrote: > So assuming we want to add new modifiers (we kinda do) how should this > be addressed? Both going forward and dealing with legacy code. My first inclination is that what you want is a way to get at the underlying structure of the regex so you can query what flags there are on it

Failures in pre-requisites

I wrote: > Salve J Nilsen wrote: > > Bug #4: There isn't a sufficiently clear test output summary telling > > Joe which module broke the dependency chain - so he can't look into > > it himself. Visualizing the dependencies and show where it broke > > may help. Maybe displaying the relevant depend

Re: running author tests

On 8/2/07, Andy Armstrong <[EMAIL PROTECTED]> wrote: > On 2 Aug 2007, at 23:53, Eric Wilhelm wrote: > > I think a new toplevel (e.g. ./author_t or ./author_test) directory is > > going to be most compatible. > > +1 Agree, +1 for "author_t" -- using "t" rather than "test" is a better parallel to th

Re: Tests involving regexes

Not a solution to your problem but I just want to point out that the correct way to write regex tests is is($re, qr/what I expected/); and that this will never be upset by changes like demerphq is describing, F On 03/08/07, demerphq <[EMAIL PROTECTED]> wrote: > Hi, > > I thought id bring a tric

Tests involving regexes

Hi, I thought id bring a tricky subject that ive encountered in Perl core development up here so you testing mavens can have a look at the problem and maybe come up some suggestions for me. The problem is this: one of the main obstacles for adding new regex flags to the perl regex engine are the

Re: Summarizing the pod tests thread

Salve J Nilsen wrote: Bug #1: The module build output text is too verbose. (Hiding the detailed output would be useful.) It certainly is, especially when there's XS things being built. The vast majority of the time all you're interested in is failures, no-one cares that yet another

Re: Revising the Perl Testing quick reference card

On 2 Aug 2007, at 19:05, nadim khemir wrote: [snip] Test::Block [snip] I (personally) don't think T::B is generally useful enough. These days I'd push things like Test::Group / Test::Class instead. Cheers, Adrian

Re: Summarizing the pod tests thread

* A. Pagaltzis <[EMAIL PROTECTED]> [2007-08-03 09:08]: > I’d suggest `aut_t`. Err, `auth_t`. Regards, -- Aristotle Pagaltzis //

Re: Fixing the damage caused by has_test_pod

* Andy Lester <[EMAIL PROTECTED]> [2007-07-30 22:30]: > On Jul 30, 2007, at 2:46 PM, A. Pagaltzis wrote: > > > >>Certainly, the intent is to have boilerplate.t NOT get > >>shipped with the module. > > > >Disagree. The tarball should contain the full source necessary > >to recreate everything the a

Re: Summarizing the pod tests thread

* Adam Kennedy <[EMAIL PROTECTED]> [2007-08-01 05:25]: > David Golden wrote: > >* Alternatives -- Eric Wilhelm suggests putting these tests in > >at/ and running them with prove. Likewise, Module::Build and > >ExtUtils::MakeMaker could have targets added that run tests in > >an "at/" directory as