On Wed, Nov 19, 2003 at 07:17:46AM -0800, Randal L. Schwartz wrote:
> Michael> For that reason I'd agree with Curtis and say that
> Michael> everything is always run by default and users can then elect
> Michael> what to turn off. PERL_SKIP_LONG_TESTS seems like a clear
> Michael> name.
>
> As
> "Michael" == Michael G Schwern <[EMAIL PROTECTED]> writes:
Michael> Disabling tests for subjective reasons (they take "too long",
Michael> they don't test critical functionality, etc...) is a slippery
Michael> slope.
But there are clearly tests that are "tip of the iceberg" as a safety
chec
On Wed, Nov 19, 2003 at 01:45:31PM +1100, Andrew Savige wrote:
> I think the two environment variables can happily coexist as
> shown in the table below:
>
> PERL_SMOKE PERL_SKIP_LONG_TESTS
> Naive User0 0
> Contrary User 1
Michael G Schwern wrote:
Disabling tests for subjective reasons (they take "too long", they don't
test critical functionality, etc...) is a slippery slope.
I've seen this approach used successfully in a commercial setting. The
key is to make sure that the long tests do get run by someone.
If u
Michael G Schwern wrote:
> Disabling tests for subjective reasons (they take "too long", they don't
> test critical functionality, etc...) is a slippery slope. For that reason
> I'd agree with Curtis and say that everything is always run by default
> and users can then elect what to turn off. PER
On Wed, Nov 19, 2003 at 09:30:19AM +1100, Andrew Savige wrote:
> > Also, I would recommend something like PERL_SKIP_LONG_TESTS. By
> > default, all tests should be run to prevent the user accidentally
> > forget to run some tests.
>
> If some tests take hours to run, running them by default will
Ovid wrote:
> --- Kate L Pugh wrote:
> > This was discussed on this list back in June. I'm wanting to
> > implement it now and am wondering if Andrew's suggestion (below) has
> > been taken up by anyone. Is PERL_TEST_LONG what people here
> > generally
> > expect to be the right environment varia
--- Kate L Pugh <[EMAIL PROTECTED]> wrote:
> This was discussed on this list back in June. I'm wanting to
> implement it now and am wondering if Andrew's suggestion (below) has
> been taken up by anyone. Is PERL_TEST_LONG what people here
> generally
> expect to be the right environment variable
This was discussed on this list back in June. I'm wanting to
implement it now and am wondering if Andrew's suggestion (below) has
been taken up by anyone. Is PERL_TEST_LONG what people here generally
expect to be the right environment variable to set to enable
long-running tests?
(I know I could
You beat me to it, but I think PERL_SMOKE would be better.
The automated tools that need to run the long tests instead of the short
tests are the "smokers".
Except that "smoke" has the context of the perl distro tests that are
getting done. If anybody's gonna be using the "smoke" concept, it'll
On Thu, Jun 05, 2003 at 10:55:29AM +0100, Mark Fowler wrote:
> On Thu, 5 Jun 2003, [iso-8859-1] Andrew Savige wrote:
>
> > While a standard name is not required, having one would allow
> > automated CPAN test harnesses to run the longer tests.
>
> While we're on it, it'd be nice to have a standar
> "Andrew" == Andrew savige <[EMAIL PROTECTED]> writes:
Andrew> Since no experienced perl-qa'er has leapt in, and against my better
Andrew> judgement, I suggest an environment variable name of:
Andrew> PERL_TEST_LONG
You beat me to it, but I think PERL_SMOKE would be better.
The automated to
On Thu, 5 Jun 2003, [iso-8859-1] Andrew Savige wrote:
> While a standard name is not required, having one would allow
> automated CPAN test harnesses to run the longer tests.
While we're on it, it'd be nice to have a standard enviromental variable
that turned off all interactivty. Make the modul
Mark Fowler wrote:
> On Thu, 5 Jun 2003, [iso-8859-1] Andrew Savige wrote:
>
> > While a standard name is not required, having one would allow
> > automated CPAN test harnesses to run the longer tests.
>
> While we're on it, it'd be nice to have a standard enviromental
> variable that turned off
Randal L. Schwartz wrote:
> All I'm asking for in my quest is to keep the "install health check"
> tests down to a minute or two. Remember that CPAN.pm insists that
> "make test" works before I can install.
I agree. Modules should commonly have long-running exhaustive tests
and/or stress tests. T
> "Adrian" == Adrian Howard <[EMAIL PROTECTED]> writes:
Adrian> I don't see it as a real problem. If I've written a test I want it
Adrian> run. Otherwise I wouldn't have written it. Not running tests is pretty
Adrian> much the ultimate sin as far as I am concerned - but I'm odd that way
Adrian
Randal L. Schwartz wrote:
> No, it doesn't need a standard name. The default should be the
> "install tests" without any special envar. The developer can select
> their own set of envars to control various *longer* tests.
While a standard name is not required, having one would allow
automated CP
> "Andrew" == Andrew Savige <[EMAIL PROTECTED]> writes:
Andrew> Randal L. Schwartz wrote:
>> All I'm asking for in my quest is to keep the "install health check"
>> tests down to a minute or two. Remember that CPAN.pm insists that
>> "make test" works before I can install.
Andrew> I agree. M
On Sunday, June 1, 2003, at 08:43 am, Andrew Savige wrote:
Merlyn's use perl journal of April 29, 2003:
http://use.perl.org/~merlyn/journal/
suggests using environment variables to spare the installer of
CPAN modules a long wait while running 'make test'. One reply
noted that DBD, HTML::Mason an
Merlyn's use perl journal of April 29, 2003:
http://use.perl.org/~merlyn/journal/
suggests using environment variables to spare the installer of
CPAN modules a long wait while running 'make test'. One reply
noted that DBD, HTML::Mason and other modules already do this.
Is there a standard name/s
20 matches
Mail list logo
