On Wed, Mar 5, 2008 at 4:57 PM, Andy Armstrong <[EMAIL PROTECTED]> wrote:
> On 5 Mar 2008, at 19:53, Mark Overmeer wrote:
> >> So now we just need to backport that to Perl 5 and convert every
> >> extant POD parsing tool. What could possibly go wrong?
> >
> > Damian has made an implementation i
On Wed, Mar 5, 2008 at 4:28 PM, Andy Armstrong <[EMAIL PROTECTED]> wrote:
> On 5 Mar 2008, at 19:23, Adriano Ferreira wrote:
> > =for method
> >
> > has the least impact (if the next paragraph is left blank). According
> > to the specs, it should be understoo
On Wed, Mar 5, 2008 at 3:35 PM, David Golden <[EMAIL PROTECTED]> wrote:
> On Wed, Mar 5, 2008 at 1:06 PM, Ian Malpass <[EMAIL PROTECTED]> wrote:
> > How about:
> >
> > =for method
> >
> > =head2 C
> >
> > Bit ugly, but it should work. Additional stuff after "method" could
> > p
On 8/17/07, brian d foy <[EMAIL PROTECTED]> wrote:
> In article
> <[EMAIL PROTECTED]>, Adriano
> Ferreira <[EMAIL PROTECTED]> wrote:
>
>
> > Testing some Author stuff would be rarer than having author tests. So
> > maybe we could standardize on somethin
On 8/17/07, chromatic <[EMAIL PROTECTED]> wrote:
> On Friday 17 August 2007 09:31:50 Christopher H. Laco wrote:
>
> > chromatic wrote:
>
> > > I've used t/author/ for quite a while without any compatibility issues.
>
> > Right, accept when your t/author tests are tests for you, the author and
> > m
On 8/17/07, Christopher H. Laco <[EMAIL PROTECTED]> wrote:
> chromatic wrote:
> > On Thursday 16 August 2007 20:14:31 Eric Wilhelm wrote:
> >
> >> I am certain that more than one 'extra tests' directory is needed, thus
> >> the thought to make them into subdirectories (objections?)
> >>
> >> (They
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 7/31/07, David Cantrell <[EMAIL PROTECTED]> wrote:
> Steffen Mueller wrote:
>
> > Does this do what you want?
> > http://search.cpan.org/~corion/Test-Without-Module-0.09/
>
> Doesn't do what I want, as I want to be able to "infect" any perl
> processes that might get exec()ed by the one from whi
return $self->has_plan;
}
Comments? Ok, returning to Warnock state (this time it would not be my
sole fault as there is a patch now for real).
Adriano Ferreira
On 4/24/07, Bugs in Test-Simple via RT <[EMAIL PROTECTED]> wrote:
Greetings,
This message has been automatically generated in res
On 4/24/07, Ovid <[EMAIL PROTECTED]> wrote:
--- Adriano Ferreira <[EMAIL PROTECTED]> wrote:
> While fussing around with some testing code, I've found that this
> script:
>
> #!/usr/bin/perl
>
> use Test::More;
>
> my $Test = Test::Builder-&g
On 4/24/07, Adrian Howard <[EMAIL PROTECTED]> wrote:
On 24 Apr 2007, at 12:30, Adriano Ferreira wrote:
[snip]
> I would really expect that "plan skip_all => $reason" was meant to do
> "Test::Builder->new->has_plan" to return a true value. According t
While fussing around with some testing code, I've found that this script:
#!/usr/bin/perl
use Test::More;
my $Test = Test::Builder->new;
plan skip_all => "I'm leaving NOW!";
END { print "Bye" unless $Test->has_plan }
produces the ouput
$ perl t-builder.t
1..0 # Skip I'm
already - an information which is nowhere
else. Other examples may follow.
My $0.02.
Adriano Ferreira.
If I run this script
use Test::More;
plan tests => 2;
BEGIN { use_ok( 'My', 'foo' ); }
ok(1);
is(foo, 1);
I got the output, which says nothing about the use_ok. It is not
counted as a test, it does not ruin the plan, it does its job
(requiring and importing a &foo subroutine).
ulo argument checking)
it seems the case, since Ccurrent_test>
is part of the public API.
Of course, the other part that concerns Gabor - having
the harness check the plan at the end to make sure
the test script spitted a plan - is worthy to consider
and is not addressed here.
Regards,
Adriano Ferreira
On 7/20/06, A. Pagaltzis <[EMAIL PROTECTED]> wrote:
use Test::More;
plan tests => my $tests;
{
require_ok( 'MyModule' );
my $obj = MyModule->new();
isa_ok( $obj, 'MyModule' );
}
BEGIN { $tests += 3 }
[snip clever code]
Like Schwern said, this stuff
On 7/20/06, David Wheeler <[EMAIL PROTECTED]> wrote:
You probably could have used Test::More->builder->expected_tests to
set the sample sized based on whatever value you put into the plan.
I didn't know about Test::Builder->expected_tests, but from the code
of Test::Builder 0.33 it looks like i
On 7/20/06, chromatic <[EMAIL PROTECTED]> wrote:
I don't understand this. I have a Vim macro that switches between:
use Test::More 'no_plan';
... and:
use Test::More tests => 1;
When I work on a test suite, I switch off the plan. When I finish, I look at
the number of tests
On 7/20/06, Hakim Cassimally <[EMAIL PROTECTED]> wrote:
Restructuring your tests (moving OS-dependent, skippable sections to
their own scripts for example) might make the requirement for a
deferred plan seem less important ?
Writing tests is harder. Writing code is more rewarding to the heart.
On 7/20/06, Andy Lester <[EMAIL PROTECTED]> wrote:
On Jul 20, 2006, at 2:19 PM, Adriano Ferreira wrote:
> was emitted, it would mean the test *should* tell the plan at the end.
> If it doesn't, it is a failure. I don't think this is no protection.
> It may be an im
On 7/20/06, Adriano Ferreira <[EMAIL PROTECTED]> wrote:
When something like
> >>> use Test::More tests => 'defer';
was emitted, it would mean the test *should* tell the plan at the end.
If it doesn't, it is a failure. I don't think this is n
On 7/20/06, Michael Peters <[EMAIL PROTECTED]> wrote:
>> What benefit would that give? plan() is nice because it provides protection
>> against you test script exiting prematurely.
>
>
> The exact same benefit as doing a 'plan' at the
> beginning, except this would work for scripts that don't k
On 7/20/06, Michael G Schwern <[EMAIL PROTECTED]> wrote:
On 7/20/06, Gabor Szabo <[EMAIL PROTECTED]> wrote:
> On the other hand I can count them during the test and can tell
> Test::More that I was actually expecting $n tests.
This is exactly how no_plan works.
use Test::More 'no_plan';
Te
On 7/12/06, Gabor Szabo <[EMAIL PROTECTED]> wrote:
While checking if the versions of all the modules are as
required in our installation I am using the following one liner to
fetch the version numbers.
perl -MModule -e'print $Module::VERSION'
This one-liner doesn't work all the time in modul
On 11/8/05, David Landgren <[EMAIL PROTECTED]> wrote:
> >> Adam Kennedy wrote:
> >>> Doesn't makemaker only like you if you have a single .pm file just in
> >>> the root directory?
> >>> And otherwise you have to have your lib files actually under lib?
> The trouble is... I *like* having the file
On 9/25/05, Randy W. Sims <[EMAIL PROTECTED]> wrote:
> D'oh. I shoulda taut a dat. I tried defining sub Module::import {die}
> which works for C, but not C. I thought of pushing coderef
> on @INC, but it don't work for older perls. Ivan's suggestion of
> Devel::Hide, while doing exactly what I want
Here is another patch. No --list anymore. Just --seed. There is also a
new test script "t/prove-shuffle.t". It touches the MANIFEST and
tweaks "t/prove-globbing.t" which depends on distribution files
matching "t/prove*.t".
Adriano.
prove-patch
Description: Binary data
On 7/26/05, Michael G Schwern <[EMAIL PROTECTED]> wrote:
> Yeah, that's exactly what I was worried about. Why not just write:
> prove -b -D -d 1 2 0 3 4
> this even avoids having to write special code to handle Andy's worry about
> large lists of arguments.
I see your point and agree. Pro
On 7/25/05, Michael G Schwern <[EMAIL PROTECTED]> wrote:
> > prove --shuffle --list=5,4,0,1,2,3 t # the shuffle list is predetermined
>
> I'm not sure I see the utility in that last one that significantly beats
> out just reordering the arguments to prove. Do you have a use case? And
> what ha
I have forgotten to say that the patch is over the source code of
"bin/prove" in "Test-Harness-2.53_01.tar.gz".
Adriano.
Andy,
I have written a patch to approach the TODO item of "prove":
Shuffled tests must be recreatable
"prove" still works the same, but with extra options to control
--shuffle option.
prove --shuffle t # runs shuffled 't/*.t' scripts (as usual)
prove --shuffle --seed=808208 t # shu
31 matches
Mail list logo
