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