# from Ovid
# on Thursday 04 January 2007 01:34 pm:
>However, if you use the '-s' switch to shuffle your tests and bailout
>is not first, then some tests will run until the BAIL_OUT is hit.
> This seems to violate the principle that tests should be able to run
> in any order without dependencies.
# from Andy Lester
# on Thursday 04 January 2007 06:25 pm:
>On Jan 4, 2007, at 8:17 PM, Eric Wilhelm wrote:
>> Is it possible to shuffle all but the first tests?
>
>No. You either have tests that are ordered, or you don't.
Stated as if it were some sort of immutable law
# from Ovid
# on Friday 05 January 2007 01:50 am:
>TAPx::Parser collects far more
>information than Test::Harness, so if there's more stuff you'd like to
>see, that's fine, too.
You could dump it all into some kind of data (yaml?) file, then execute
$ENV{TAP_RESULTS_VIEWER} or something?
TAP_RE
Hi all,
Anybody like testing and depend on PAR to work? If so, Module::ScanDeps
*badly* needs your help. There are currently only two tests, one of
which is conditional on Module::Pluggable, the other of which doesn't
provide much coverage.
What's the best way to test this sort of thing?
I
# from Andy Armstrong
# on Sunday 21 January 2007 09:21 am:
>> OR possibly even...
>>
>> /home/me/directory/ADAMK/Dist-Name-0.01.tar.gz/01_compile.t
>> /home/me/directory/ADAMK/Dist-Name-0.01.tar.gz/02_main.t
>
>That might be harder. I guess whatever harness you use to set the
>environment varia
# from Andy Armstrong
# on Sunday 21 January 2007 11:37 am:
>On 21 Jan 2007, at 19:16, Eric Wilhelm wrote:
>> PERL_TEST_HARNESS_DUMP_TAP="$(test_dir_for_this_dist)"
>>
>> If that isn't enough (which may be the case in Adam's cpan
>> injection),
# from Smylers
# on Sunday 21 January 2007 11:50 pm:
>Eric Wilhelm writes:
>> If that isn't enough, I suppose you could do "if the env var is an
>> executable, run it and capture the output"?
>
>Nice -- so that if you manage to trick somebody into setting th
# from Adam Kennedy
# on Tuesday 09 January 2007 03:05 am:
>Since I moved to SVN, one of the things I've been doing is commiting
> my release tarballs into a /releases/ directory.
>
>One side-effect of this is that even before I've uploaded it to CPAN,
>ever release already has a URI.
I was doing
# from Nadim Khemir
# on Tuesday 30 January 2007 09:17 am:
> # all Test::Exceptions subroutines are guaranteed to preserve the
> state # of $@ so you can do things like this after throws_ok and
> dies_ok like $@, 'what the stringified exception should look like';
>
>This wouldn't be needed if die
Hi all,
I was just thinking that since my tests are nicely orthogonal and yet
there's very little cpu utilization during testing, that I could
probably get them done about 20x faster if they were parallelized.
Has anyone looked at doing this with TAPx::Harness or otherwise? Is
there a big und
# from Nicholas Clark
# on Monday 05 February 2007 03:24 am:
>which was sufficient to give a lot of flexibility in how tests were
> run (and discover that the core is very unoriginal in its naming of
> temporary files)
# from Adam Kennedy
# on Monday 05 February 2007 03:41 am:
>Each test is stil
# from Andy Armstrong
# on Monday 05 February 2007 04:20 am:
>I can't remember whether it's mod_perl or CGI.pm that launches Apache
> a few times during testing but I imagine there might be a problem
> with multiple Apaches trying to bind to the same port in that case
> too. Ditto anything that
# from Andy Armstrong
# on Monday 05 February 2007 10:27 am:
>I guess there are already frameworks
>available that'd help with managing that kind of distributed setup?
>The most similar thing I have any experience of is distcc[1].
>
>As a matter of interest I wonder if anyone's worked out whet
It seems that exec accumulates arguments, thus running the first test
over and over with more and more arguments.
http://scratchcomputing.com/tmp/tapx_exec.patch
The runtests utility was also passing a string from the '-e' switch.
The split(/ /, ...) is a little naive, but demonstrates the i
# from Andy Armstrong
# on Monday 05 February 2007 11:22 am:
>To run tests locally you need to
>
>* launch the tests in // and gather their output
>* display the test progress / results differently
>* make it possible to attach some metadata to tests
> that describes such things as which tests
# from Nicholas Clark
# on Monday 05 February 2007 03:24 am:
>Important differences were
>
>1: you only print out the entire test results as an atomic line when
> it has finished
>2: You have no idea which test is going to finish next
>3: You can't print running progress on tests
Ah, there's the
# from Andy Armstrong
# on Monday 05 February 2007 12:23 pm:
>We could just ship the raw TAP
>back along with the test summaries I guess.
Is that what the 'tap' field is for, or is that intended for input?
Maybe the definition of freeze/thaw should recycle that field?
--Eric
--
You can't wh
# from Ovid
# on Tuesday 13 February 2007 01:16 am:
>--- Kirrily Robert <[EMAIL PROTECTED]> wrote:
>> Does anyone here understand "fixtures" as a testing concept, and
>> could they please explain it to me in a Perlish way?
>>
>> At least half of what I've heard described is what I usually achieve
Apologies for the cross-post. We should probably discuss it on perl-qa,
but I wanted to keep module-build informed.
So, it turns out that the implementation that we came up with can't be
so handy. Originally, I had done this to just run files with different
extensions. During the hackfest, w
# from Michael G Schwern
# on Monday 26 February 2007 01:50 pm:
>And then someone defined a $SIG{__DIE__} so now its C<<{ local
>$SIG{__DIE__}; eval { $obj->isa($class) } }>>
No. If that $SIG{__DIE__} doesn't check $^S, then it's just
delete($SIG{__DIE__}) and you're back to eval {$obj->isa($c
# from Michael G Schwern
# on Monday 26 February 2007 03:29 pm:
>Eric Wilhelm wrote:
>> # from Michael G Schwern
>>
>> # on Monday 26 February 2007 01:50 pm:
>>> And then someone defined a $SIG{__DIE__} so now its C<<{ local
>>> $SIG{__DIE__}; eval
# from Michael G Schwern
# on Monday 26 February 2007 05:53 pm:
>Put another way... be lax in what you accept, strict in what you
>output.
That's a different subject having more to do with piped text than code
(if anybody in this case is being strict about acceptance here, it's
perl) and even
# from Michael G Schwern
# on Monday 26 February 2007 09:20 pm:
>>breaking broken code is easier than
>> accounting for ignorance with the unfortunate side-effect that the
>> user learns something. The ignorance goes away and balance is
>> restored.
>
>Again, you're assuming the "user" here to be
# from Andrew Gianni
# on Thursday 01 March 2007 08:42 am:
>However, our business rules
>have gotten complicated enough that we are no longer writing them that
> way explicitly in the code. In the last application we built, we put
> the rules in a database and the appropriate ones were pulled base
At the bottom of a test file:
{my $finish = 1; END {$finish or die "\n unplanned exit"}};
Yeah, you have to remember to put it at the end of the file, but it may
be easier than counting tests. Thoughts? Maybe an 'until_done'
directive and 'tests_done' function? Ways to check that there is
# from Andy Lester
# on Saturday 03 March 2007 06:18 pm:
>Good Lord do I get frustrated at the handwringing over test
>counting. Look, it's simple. You write your tests. You run it
>through prove. You see how many tests it reports. You add it at the
> top of the file. Voila!
I'm not w
# from Ricardo SIGNES
# on Saturday 03 March 2007 07:11 pm:
>> use inc::testplan(0,
>> + 3 # use
>> + 199 # those others
>> );
>
>What is that ... for?
It's a substitute for
use Test::More (0 ? (no_plan) : (tests => 202));
... mostly because I don't like the number of parens in
# from Dominique Quatravaux
# on Sunday 04 March 2007 04:33 am:
>And what if you are running a variable number of tests depending on
>stuff such as compile-time options, maintainer mode enabled or not, or
>whatever?
Even under no_plan, I would say you should use skip() there.
--Eric
--
"Time fl
# from Sébastien Aperghis-Tramoni
# on Sunday 04 March 2007 06:19 am:
> use Test::More;
>
> my $tests;
> plan tests => $tests;
>
> BEGIN { $tests += n }
> # paragraph of code with n tests
>
> BEGIN { $tests += m }
> # paragraph of code with m tests
Interesting. What i
# from brian d foy
# on Sunday 04 March 2007 10:02 am:
>I run into problems where a loop runs fewer iterations than it should
>but the test script otherwise runs to completion normally.
I typically treat that as a test case.
my $counter = 0;
for(things(@foos)) {
ok($_);
$counter++;
# from A. Pagaltzis
# on Sunday 04 March 2007 12:42 pm:
>* Eric Wilhelm <[EMAIL PROTECTED]> [2007-03-04 08:20]:
>> It's a substitute for
>>
>> use Test::More (0 ? 'no_plan' : (tests => 202));
>>
>> ... mostly because I don't lik
# from Ovid
# on Monday 05 March 2007 06:26 am:
>--- Andy Lester <[EMAIL PROTECTED]> wrote:
>> I'm very wary of potentially hidden files causing changes to whether
>> my tests pass or not. "Gee, these tests pass for me, but not for
>> you..." caused by a hidden .rc file. :-(
Sure, but that might
# from Ovid
# on Monday 05 March 2007 05:38 am:
>I have no idea what to name that switch, though, as 'warnings' is
>already taken to enable warnings in the programs. '--tap-warnings' is
>probably a decent choice even though I prefer '--squeal-like-a-pig'.
--have-a-good-talking-to
--tsk
--E
# from brian d foy
# on Monday 05 March 2007 10:41 am:
>In article <[EMAIL PROTECTED]>, Ricardo
>
>SIGNES <[EMAIL PROTECTED]> wrote:
>> * brian d foy <[EMAIL PROTECTED]> [2007-03-04T12:09:26]
>>
>> > I'm not talking about the particular field name, but the idea that
>> > I'd want to say in META.ym
# from Ricardo SIGNES
# on Monday 05 March 2007 10:09 am:
>* brian d foy <[EMAIL PROTECTED]> [2007-03-04T12:09:26]
>
>> ... without me having to
>> change the META.yml in all of my distributions then re-uploading
>> them all.
>
>So, for some subset of META.yml settings, you could consult the
> mod
# from Michael G Schwern
# on Tuesday 06 March 2007 04:40 pm:
>Eric Wilhelm wrote:
>> At the bottom of a test file:
>>
>> {my $finish = 1; END {$finish or die "\n unplanned exit"}};
>>
>> Yeah, you have to remember to put it at the end of the file,
# from Julien Beasley
# on Friday 09 March 2007 03:39 pm:
>Thanks Ovid! This may be exactly what I'm looking for (since I'm going
> to have tests in libtap and perl). However, and I apologize if I'm
> wrong about this, doesn't your proposed solution have to start a new
> perl interpreter for every
# from Eric Wilhelm
# on Friday 09 March 2007 06:26 pm:
>However, if you feel the need for speed, I *think* you could add
> support in runtests for "--exec ''" to turn into @exec=() rather than
> @exec=('').
Darn! That sounded like so much fun. I just co
# from Andy Armstrong
# on Friday 09 March 2007 04:47 pm:
>I'm just adding support for specifying the TAP version number[1] to
>TAPx::Parser. It seems reasonable that the version, if present,
>should be the first thing in the TAP.
I think that should always be the case. While I don't forsee
# from Michael G Schwern
# on Monday 12 March 2007 04:49 pm:
>If all we do is argue about TAP extensions and never actually produce
> one we will never have to worry about new versions!
That's a good plan. To implement it, we really need a committee.
Perhaps perl-qa is a little overwhelmed wit
# from chromatic
# on Wednesday 14 March 2007 01:47 am:
>They don't have to interfere with the TAP stream unless they call
>Test::Builder->diag(),
Yep. We need to flow everything from stderr through asap. However, I
don't think we should be trying to do *anything* with it (except maybe
archi
The diag() debate raged on in pdx tonight. Of course, the sides are
roughly in agreement about most things, but with differing priorities
and ideas about particulars of the implementation.
Perhaps it's time to collect the issues and do some thinking.
Fundamentals:
1. Anything on STDERR canno
# from Michael G Schwern
# on Friday 16 March 2007 02:59 am:
>I chose #--- because 1) its backwards compatible as long as you ignore
> unknown directives and 2) it allows TAP to stream. Otherwise its
> pretty damn inelegant. We could say that a name ending in ---
> indicates a forthcoming TAP st
# from A. Pagaltzis
# on Friday 16 March 2007 06:08 am:
>* Michael G Schwern <[EMAIL PROTECTED]> [2007-03-16 11:55]:
>> fatal !!!
>> fail !!
>> warn !
>> notice
>> pass !!!
>> info !!
>> debug !
>
>The most bangs I can count instantly by looking at them is four.
I would say anyth
Hi!
Would anybody mind if, when the subject changes, we, uh... change the
subject line?
# from A. Pagaltzis
# on Sunday 18 March 2007 07:05 pm:
>* Andy Armstrong <[EMAIL PROTECTED]> [2007-03-19 00:35]:
>> On 18 Mar 2007, at 23:10, A. Pagaltzis wrote:
>> >* Andy Armstrong <[EMAIL PROTECTED]> [20
# from Michael G Schwern
# on Wednesday 28 March 2007 08:31 pm:
>Its base.pm.
>
> local $SIG{__DIE__};
> eval "require $base";
>
>Test::Builder::Module is loaded which loads Test::Builder which
> instantiates a __DIE__ handler which is localized and thrown out.
Hey, that is
# from ReneeB
# on Sunday 01 April 2007 12:41 am:
>On 31 Mar 2007, at 23:14, Thomas Klausner wrote:
Yay! Now that the time zones have caught up, I get to participate in
the discussion.
>>> Even though I was fighting mail servers today, I managed to put
>>> some time aside
>>> for long-needed C
# from Yuval Kogman
# on Monday 02 April 2007 03:57 pm:
>Then just proxy everything:
>For the proper distinction between a setter and a method that
>accepts arguments (and should still be shadowed) I guess you need
>some meta programming, but the value is dubious IMHO.
My first thought was actual
# from Andy Armstrong
# on Wednesday 04 April 2007 05:58 am:
> runtests t/*.t --select regression,docs
>
>Would select only regression and documentation tests. That's just an
>example plucked out of the ether of course - it wouldn't /have/ to
>work like that.
Meaning that every test has to d
# from Philippe Bruhat (BooK)
# on Wednesday 04 April 2007 05:42 am:
>Usually because I want to run a specific subset of tests only.
>
>A typical example is:
>
> $ AMS_REMOTE=1 perl -Ilib t/90up2date.t simpsons
> 1..26
> # Testing 13 themes using the network (may take a while)
> ok 1 #
# from chromatic
# on Wednesday 04 April 2007 11:24 am:
>> Can we think about this in terms of the producer supporting some
>> sort of dynamic skip concept involving labels or such? Possibly a
>> bit of yaml shoved in an environment variable?
>
>It seems to me that we already have a good way of s
# from Andy Armstrong
# on Thursday 05 April 2007 02:18 am:
>> I added a concept of "test profiles" to Module::Build
>> for just this sort of thing. You make your gui tests be '.gt'
>> files, your author tests '.at' files, ...
>
>I think I'd rather put my tests into subdirectories to group them
# from Philippe Bruhat (BooK)
# on Thursday 05 April 2007 02:29 am:
>No, I've already solved that problem by putting the tests in separate
>directories. E.g., I've now a single pod.t file in test/pod that
>will use Test::Pod on all the files in cwd (or the files passed as
>command line parameters
Hi all,
The only easter egg I got today was this conundrum:
Pod::Coverage reports aliased methods as undocumented because
Method::Alias does the eval("package $your_package; sub $alias
{shift->$canonical([EMAIL PROTECTED])}") thing.
Of course, it doesn't bother reporting things like accessors
# from Eric Wilhelm
# on Sunday 08 April 2007 09:41 pm:
>Alternatively, maybe what I want is just for Pod::Coverage to not
> check any symbols that aren't static subs in the package in question.
> (I guess that would solve the whole @INC bug as well and we could
> just statica
# from Ricardo SIGNES
# on Monday 09 April 2007 05:10 am:
>I need to finish/test/release my PC subclass that looks at
>@PKG::POD_COVERAGE_TRUSTME.
I saw that in rt, but I really think pod is the place for it. Why
clutter the code with variables which are only used by a tool that
reads pod? Is
# from Andy Armstrong
# on Sunday 01 April 2007 07:53 am:
>Agreed. May I propose the additional requirement that the
>documentation contain a lengthy treatise on the benefits of true[1]
>object orientation?
>
>[1] For whichever value of 'true' the author prefers.
Yes, but then it should also
# from Ovid
# on Monday 16 April 2007 02:29 am:
>I need to skip the
>rest of the tests, but I want to use a plan and I don't want to keep
>counting the number of tests after the skip.
...
> my $remaining_tests = looks_like_number($plan)
> ? $plan - $builder->current_test
> : 1;
# from Nadim Khemir
# on Wednesday 09 May 2007 10:51 pm:
>PAR has a module to find module dependencies. That might help.
That would be Module::ScanDeps. Needs tests. The static scanning is
not using PPI, and I think everyone involved at this point agrees that
it should. There is also a lot o
# from Matisse Enzer
# on Sunday 20 May 2007 08:55 am:
>So - what's the "right" way to remedy this?
>
> - The author (that's me!) provides a Makefile.PL as well as Build.PL?
> - Fix something in the CPAN tester system?
> - Other?
> - Some combination of the above ? :-)
http://www.nntp.perl.or
# from demerphq
# on Saturday 26 May 2007 10:45 am:
>> Sorry, but it is *the _compression_ software's* bug.
>
>Fine, then what do i do about it? File a bug with Archive::Tar
>(maintained by a non windows programmer)?
This should be properly handled by the dist action of any sufficiently
modern M
# from Gabor Szabo
# on Wednesday 30 May 2007 08:58 pm:
>I would like to be able to opt-in such e-mail
>reports.
>Similarly to how CPAN Testers send reports.
Wouldn't it would be interesting if there were a multiplexing service
for this sort of thing? E.g. maybe a system that allows you to
sub
# from Ian Malpass
# on Wednesday 06 June 2007 08:08 am:
> * Has copyright details
> * Has license details
On bigger projects, these things sometimes get done as "see the main
module documentation for copyright and license statement". Thus, it
would be good for this to be configurable
# from Andy Armstrong
# on Thursday 07 June 2007 03:13 pm:
>I'd like an editor that lets me look at it either way. Sometimes I
>want to look at uninterrupted code - in which case interleaved
>documentation just gets in the way. Other times it's nice to be able
>to read the code while documen
# from Andy Armstrong
# on Thursday 07 June 2007 03:44 pm:
>I definitely think
>
>$ podlifter -end lib/My/Stuff.pm
>
>and
>
>$ podlifter -interleaved lib/My/Stuff.pm
>
>need to exist.
Ingy had something in that vein, but I'm not sure it does the round
trip.
Also, podadz
http://scratchcomputing
# from Joshua ben Jore
# on Thursday 07 June 2007 05:14 pm:
>On 6/7/07, Eric Wilhelm <[EMAIL PROTECTED]> wrote:
>> I've never seen the benefit of pod after __END__. IMO, your code
>> and docs should follow the same order/groupings.
>
>It has two benefits.
>...r
# from A. Pagaltzis
# on Thursday 07 June 2007 10:25 pm:
>Documentation should form a coherent narrative. The myopic view
>of inlined local POD sections is a hindrance to that.
We need to be able to switch the folding between pod and not-pod, eh?
>Conversely,
>when I edit code, I occasionally
Thoughts?
I can override CORE::GLOBAL::time() and I've done this before with a
closure (ala Time::Mock), but how would one implement accelerated time
for testing a multi-process program?
I'm also dealing with possibly sleep(), alarm() and other timing issues,
as well as maybe Time::HiRes::tim
# from Adam Kennedy
# on Saturday 28 July 2007 09:38 am:
>Thus, I would like to propose the following.
>
>1. That the running of POD-related tests by end users is considered
> harmful.
+20
>2. That the test_pod and test_pod_coverage tests by modified, such
> that these tests check for the mentio
# from Adam Kennedy
# on Saturday 28 July 2007 01:52 pm:
>Unfortunately, the pod coverage tests requires the module to be
>compiled, so CPANTS can never safely run it, and thus can never run it
>at all. :)
No. *Pod::Coverage* requires the module to be compiled. Testing the
coverage of pod does
# from Christopher H. Laco
# on Sunday 29 July 2007 08:00 am:
>It's rare, but I've been in the situation where
>for some reason (mistmatching dist requirements, failed upgrades, bad
>dist packages, broken troff, etc) the creation of man pages/html from
>the dist pod fails outright.
That reinforce
# from David Golden
# on Monday 30 July 2007 05:34 am:
>The issue at hand is really *release* testing (i.e. did I bump the
>version, did I test my Pod, do I use good style, etc.) being mixed
>with *functional* testing -- and the corresponding push for release
>testing modules being included as req
# from Christopher H. Laco
# on Monday 30 July 2007 11:14 am:
>I don't agree. What runs when I do 'make test' is up to me, and if I
>want to litter it up with 'author' tests, then that's my business;
> right or wrong. Don't like it, then don't use my modules. (I still
> think all author tests shou
# from David Golden
# on Monday 30 July 2007 01:06 pm:
># pod-coverage.t
>use Test::More;
>plan skip_all => "Skipping author tests" if not $ENV{AUTHOR_TESTING};
>
>my $min_tpc = 1.08;
>eval "use Test::Pod::Coverage $min_tpc";
>plan skip_all => "Test::Pod::Coverage $min_tpc required for testing
No
# from chromatic
# on Monday 30 July 2007 01:39 pm:
>On Monday 30 July 2007 13:19:56 Christopher H. Laco wrote:
>> Eric Wilhelm wrote:
>> > If *you* don't have Test::Pod, and *I* do, *I* cannot install your
>> > module if the pod doesn't pass.
>>
&g
# from Christopher H. Laco
# on Monday 30 July 2007 01:35 pm:
>If it fails and you can't install it, then don't.
>Arguments about whether the tests should or shouldn't be run [or
>included at all] is irrelevant. Tests failed. Don't install.
I think you're looking at this as "oh, I'll try whiz-ba
# from David Golden
# on Monday 30 July 2007 05:03 pm:
>>Or,
>> simply the hardcore CPAN author who put it in their .bashrc and
>> forgot about it
^-- who will it bite first, will it be him, her, or me?
>> until some broken pod appeared in the middle of a
>> big dependency stack. Environmen
# from David Golden
# on Monday 30 July 2007 07:39 pm:
>On 7/30/07, Eric Wilhelm <[EMAIL PROTECTED]> wrote:
>> `mkdir at`, but I fail to understand the resistance.
>
>* CPANTS Kwalitee
>* Module::Starter
Both need correcting anyway.
>* Test::Pod::Coverage
Why does
# from David Cantrell
# on Tuesday 31 July 2007 04:27 am:
>> No. If AUTHOR_TESTING, fail miserably unless the pod and coverage
>> both 1. gets tested and 2. passes. That means the Test::Pod::*
>> module in question must load.
>
>Wrong. If AUTHOR_TESTING then surely all tests *must* pass both wi
# from Andy Armstrong
# on Tuesday 31 July 2007 05:55 am:
>> This is the approach I thought of. I think you'll need to keep a
>> persistent file of output to capture require calls across each test
>> file and then summarize. (I.e. so you can set it as a command line
>> option to the harness.)
>
# from Yitzchak Scott-Thoennes
# on Tuesday 31 July 2007 10:19 pm:
>On Tue, July 31, 2007 9:56 pm, chromatic wrote:
>> On Tuesday 31 July 2007 20:25:15 Salve J. Nilsen wrote:
>>> Turning off syntax checking of your POD is comparable to not
>>> turning on warnings in your code. Now would you publis
# from David Cantrell
# on Wednesday 01 August 2007 03:21 am:
>>> Wrong. If AUTHOR_TESTING then surely all tests *must* pass both
>>> with and *without* the optional module!
>>
>> What good does it do to skip the test if AUTHOR_TESTING? That just
>> gets us back into the same situation as the cu
Can the responsible parties please cleanup this chain of links and
shutdown/lock [1] the two abandoned wikis?
http://qa.perl.org/ [2] links to:
http://schwern.org/~schwern/cgi-bin/perl-qa-wiki.cgi links to:
http://perl-qa.yi.org/index.php/Main_Page has spam and links to:
Finally:
http://
# 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
# 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.
>>...
&g
# 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
# 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
Returning to something that came up in the 'testing pod' thread...
# from Adam Kennedy on Tuesday 31 July 2007 08:23 pm:
>A small nit, if we end up converging around the use of a relatively
>standard directory name, can we at least use something relatively
>self-evident? For example "author/"?
I
# from Smylers
# on Thursday 16 August 2007 11:40 pm:
>> I am certain that more than one 'extra tests' directory is needed,
>
>Why are you certain of this?
Because I already have a use for three 'profiles' in one project and I
can name a few others from elsewhere:
1. author (kwalitee, pod, e
# from Ovid
# on Friday 17 August 2007 12:40 am:
>> > As for the 'xt' name:
>>
>> Nobody is intuitively know what "xt" means
>
>Because 't/' is self-explanatory?
Yeah dude, it's like 't', but the x makes it eXtreme ;-)
--Eric
--
I eat your socks and you pay me.
--The business sense of a very sm
# from chromatic
# on Friday 17 August 2007 11:28 am:
>... sort of like I've been doing for at least one and probably two
> years now with Module::Build and my custom disttest action, which I
> know I've mentioned a few times now, which leads me to wonder why
> people so conveniently forget it eve
# from Michael G Schwern
# on Friday 17 August 2007 11:13 am:
>> # when something different is wanted
>> author_tests: t/developer
>
>Now you need a YAML parser to run tests, which may be fine.
But you also need to update all of the tools, which may not.
--Eric
--
But as soon as you hear the Do
# from chromatic
# on Friday 17 August 2007 01:05 pm:
>On Friday 17 August 2007 12:52:54 Eric Wilhelm wrote:
>> 1. it doesn't play nicely with recursive tests[1]
>
>"It's okay to run everything in t/ recursively" is a heuristic. You
> can tell it'
# from David Golden
# on Friday 17 August 2007 10:03 am:
>On 8/17/07, Eric Wilhelm <[EMAIL PROTECTED]> wrote:
>> 1. author (kwalitee, pod, etc)
>> 2. gui
>> 3. network
>> 4. you must have an account/password on $external_service
>> 5. pos
# from chromatic
# on Friday 17 August 2007 01:57 pm:
>On Friday 17 August 2007 13:20:39 Eric Wilhelm wrote:
>> "my project cannot use recursive tests *and* have author-only tests
>> in t/author without jumping through hoops."
>How are you getting recursive tests b
# from Smylers
# on Friday 17 August 2007 03:13 pm:
>Eric Wilhelm writes:
>Why can't gui tests simply be in t/ and be skipped if the appropriate
>environment isn't available? That way all users who are in that
>particular environment run the tests, rather than only those
# from Adriano Ferreira
# on Friday 17 August 2007 11:49 am:
>The only drawback is redundant information: there are the tests and
>the list of tests. Keeping tests in "t/" with some fine way to
>discover what they are good for (according to Chris' idea) may be
>promising if not too magical.
I thi
# from A. Pagaltzis
# on Saturday 18 August 2007 06:59 am:
>* Eric Wilhelm <[EMAIL PROTECTED]> [2007-08-18 02:25]:
>> Part of my original point is that it would be useful[1] to
>> define a standardized mapping of what functionality or
>> resources are requ
# from brian d foy
# on Saturday 18 August 2007 01:33 pm:
> the solution is probably the
>same for any other suggestions: override parts of Test::Harness to
>discover the file names you want to test, or override runtests.
Or override nothing and simply group the tests into directories.
--Eric
--
I agree with everything in this message except the choice of subject
line.
# from Ovid on Sunday 19 August 2007 05:44 am:
>What we appear to disagree on is how to handle non-MNF tests. The
> main dividing line seems to be whether we should have a separate test
> directory.
>...
>There's also th
1 - 100 of 358 matches
Mail list logo
