* David Golden <[EMAIL PROTECTED]> [2007-07-31 13:20]:
> On 7/31/07, Eric Wilhelm <[EMAIL PROTECTED]> wrote:
> > >* Test::Pod::Coverage
> >
> > Why does that matter? Does it care where its .t file lives?
>
> The synopsis suggests t/pod-coverage.t.
Wow, now that is *incredible* inertia right ther
* David Cantrell <[EMAIL PROTECTED]> [2007-07-31 13:20]:
> A. Pagaltzis wrote:
>
> >Disagree. The tarball should contain the full source necessary
> >to recreate everything the author did. Stuff that’s not
> >relevant to end-user installation of the module should simply
> >be kept out of the way.
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
--
Andy Armstrong, hexten.net
Ok, perl-qa.yi.org redirects there now and it looks like everything's
working...
Michael G Schwern <[EMAIL PROTECTED]> wrote:
> Andy Lester wrote:
> >
> > On Aug 1, 2007, at 5:09 PM, Michael G Schwern wrote:
> >
> >>> http://qa.perl.org/ [2] links to:
> >>
> >> Ask can fix that. Ask?
> >
>
# from Adriano Ferreira
# on Thursday 02 August 2007 01:13 pm:
>The behavior could be triggered by updating M::B and EUMM to make them
>run the extended glob "t/**/*.t" when PERL_AUTHOR_TESTING or
>AUTOMATED_TESTING is setted.
No. That breaks recursive tests, unless we also add code to skip
t/a
Adriano Ferreira wrote:
> On 8/2/07, David Golden <[EMAIL PROTECTED]> wrote:
>> Having an actual pod/pod-coverage.t gives a handy place to put those
>> customizations. Yes, some of that could be put in
>> "pod_coverage_options" in a config or a ACTION_testpod method, but to
>> me, that introduces
On 8/2/07, David Golden <[EMAIL PROTECTED]> wrote:
> Having an actual pod/pod-coverage.t gives a handy place to put those
> customizations. Yes, some of that could be put in
> "pod_coverage_options" in a config or a ACTION_testpod method, but to
> me, that introduces extra complexity that I don't
On 8/2/07, Eric Wilhelm <[EMAIL PROTECTED]> wrote:
> For such usage, extra dependencies would only be optional in extreme
> cases. Further, pod/pod-coverage would possibly even be 'assumed'
> tests. That is, why bother even having a .t file if the authortest
> tool knows how to run testpod and te
On 8/2/07, Scott McWhirter <[EMAIL PROTECTED]> wrote:
>
> On 8/2/07, nadim khemir <[EMAIL PROTECTED]> wrote:
> > On Tuesday 19 June 2007 17:52, Mike Malony wrote:
> > > So I'm working my project, and I've got one other more junior coder
> with
> > > me.
> > >
> > > Has anyone tried writing test fil
On 8/2/07, nadim khemir <[EMAIL PROTECTED]> wrote:
> On Tuesday 19 June 2007 17:52, Mike Malony wrote:
> > So I'm working my project, and I've got one other more junior coder with
> > me.
> >
> > Has anyone tried writing test files as part of their spec's?
> >
> > An overview document would also be
On Tuesday 19 June 2007 17:52, Mike Malony wrote:
> So I'm working my project, and I've got one other more junior coder with
> me.
>
> Has anyone tried writing test files as part of their spec's?
>
> An overview document would also be needed, and some time walking through
> the expected testing. B
On Wednesday 01 August 2007 22:10, Andrew Ford wrote:
> I have corresponded with Ian Langworth and he has agreed that I should
> revise the Perl Testing quick reference. I shall be converting it to
> LaTeX and expanding it to be a two-sided card, which implies doubling
> the amount of information
# from Salve J Nilsen
# on Thursday 02 August 2007 08:19 am:
>But this isn't a binary yes/no to POD tests issue. There's no reason
> to make this into an all-or-nothing situation. We can still let the
> end-user be the master of her own world, by allowing her to run the
> "less essential tests" on
Thanks for reading through my wall of text, Adam. :)
Adam Kennedy wrote:
Salve J. Nilsen wrote:
Let's say Joe Sysadmin wants to install the author's (a.k.a. "your")
module Useful::Example, and during the test-phase one of the POD tests
fail.
Joe Sysadmin doesn't use modules, lets try the fol
# from David Cantrell
# on Thursday 02 August 2007 02:54 am:
>Eric Wilhelm wrote:
>> # from David Cantrell
>>
>>> Skipping tests because you correctly identify that the optional
>>> module isn't available is, of course, counted as passing.
>>...
>> To test the pod, you must run the pod tests.
>
>S
# from Joshua ben Jore
# on Thursday 02 August 2007 07:13 am:
>Just FYI, using valid pod like =head3 causes runtime failures during
>build on "older" versions of Pod::Whatever that's used during the
>module installation by EU::MM.
Good point.
And still, this is something which *can* be checked a
On 7/31/07, David Golden <[EMAIL PROTECTED]> wrote:
> On 7/31/07, chromatic <[EMAIL PROTECTED]> wrote:
> > Please explain to me, in detail sufficient for a three year old, precisely
> > how:
> >
> > 1) POD can possibly behave any differently on my machine versus anyone
> > else's
> > machine, bein
Eric Wilhelm wrote:
# from David Cantrell
Let us assume that I write a module that, if you have a particular
module installed will do some extra stuff. This is very common.
...
Skipping tests because you correctly identify that the optional module
isn't available is, of course, counted as passi
18 matches
Mail list logo
