Re: running author tests
# 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.
>
>Seeing that you obviously think I'm an idiot, there's probably not
> much point continuing.
No, I just want to be clear that the pod must get tested by the pod
tests and that "eval {require Test::Pod}" is the wrong trigger if
$ENV{PERL_AUTHOR_TESTING} is set. The switch state implies that the
module is mandatory.
I (the author) don't want to accidentally skip the test due to a
missing/corrupt/old module (that is exactly why we're having problems
with the current t/pod.t invocation.)
If we're going to establish a recommendation for usage of
$PERL_AUTHOR_TESTING and/or an "author_t/" directory, it should behave
somewhat like 'use strict' in that it needs to actually run *all* of
the author tests (with very few exceptions.)
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 testpodcoverage?
--Eric
--
Like a lot of people, I was mathematically abused as a child.
--Paul Graham
---
http://scratchcomputing.com
---
Re: running author tests
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 testpodcoverage? Who says I keep my POD in same file as my code? I might put it in a separate file that has a completely different name. Or I might have a different convention for private vs public methods, etc. 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 want cluttering Build.PL. Having an "authortest/" directory that gets run with a harness is simple and consistent. Regards, David
Re: running author tests
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 want cluttering > Build.PL. Agreed in all manners. IMHO, Build.PL and Makefile.PL should be kept as dumb as possible. And easy to be read (and understood). > Having an "authortest/" directory that gets run with a harness is > simple and consistent. There is already a convention that tests go under the "t/" directory and also that they usually match the glob "t/*.t". I cannot think of anything simpler and that can possibly works, than to stick the extra tests into subdirectories of "t/" like chromatic does ( "t/author/*.t" or "t/developer/*.t" ). 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. Even programmers unaware of such conventions that are trying with the distribution, will make $ prove t/author/pod.t naturally as he/she runs any other tests. > Regards, > David >
Re: running author tests
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 extra complexity that I don't want cluttering >> Build.PL. > > Agreed in all manners. IMHO, Build.PL and Makefile.PL should be kept > as dumb as possible. And easy to be read (and understood). > >> Having an "authortest/" directory that gets run with a harness is >> simple and consistent. > > There is already a convention that tests go under the "t/" directory > and also that they usually match the glob "t/*.t". I cannot think of > anything simpler and that can possibly works, than to stick the extra > tests into subdirectories of "t/" like chromatic does ( "t/author/*.t" > or "t/developer/*.t" ). > > 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. > > Even programmers unaware of such conventions that are trying with the > distribution, will make > > $ prove t/author/pod.t > > naturally as he/she runs any other tests. > >> Regards, >> David >> > > I must say, I like t/author more than t/authortests... However, my main beef overall is now we essentially have a 'reserved name' directory that may interfere with how I may choose to group tests for larger distributions. For example, I have a boatload of tests to test http server code in t/live, and tests to test providers in t/providers and tests to test catalyst in...shockingly...t/catalyst, etc... If I have a boatload of tests for a 'author' object, I might choose to group then in t/author Sure, it's rare. Sure, I could name all those tests t/author_*.t... Either way, I think just assuming a directory name is rude. Now, if there were a way to tell the harness which directory to consider as 'author' tests.. then I guess I don't care. -=Chris signature.asc Description: OpenPGP digital signature
Re: running author tests
# 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/author/. I think a new toplevel (e.g. ./author_t or ./author_test) directory is going to be most compatible. --Eric -- "If you only know how to use a hammer, every problem begins to look like a nail." --Richard B. Johnson --- http://scratchcomputing.com ---
Re: running author tests
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
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 the existing usage of "t". David
