Re: a safer way to use no_plan?
On Sunday 04 March 2007, chromatic wrote:
On Saturday 03 March 2007 18:18, Andy Lester wrote:
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!
But Andy, what if I modify the test file? I don't want to have to modify
the test file to tell my test harness that I've modified the test file!
If only we had something that flies through space
My solution to this is:
http://search.cpan.org/dist/Test-Count/
It's not a perfect solution but it Works For Me.tm
What I do is add comments in a small domain-specific language that allow me to
count how many tests were added. These comments are usually placed close to
the tests themselves, so they can be updated at the same time. Examples for
such comments are:
# TEST
is ($mystring, Hello, String is Hello);
# TEST*3
for my $i (0 .. 2)
{
ok ()
}
Regards,
Shlomi Fish
-
Shlomi Fish [EMAIL PROTECTED]
Homepage:http://www.shlomifish.org/
Chuck Norris wrote a complete Perl 6 implementation in a day but then
destroyed all evidence with his bare hands, so no one will know his secrets.
Re: a safer way to use no_plan?
On 4 Mar 2007, at 03:40, Matisse Enzer wrote: A tangential comment: The xUnit approach avoids this question of counting altogether - you create one or more subroutines whose names begin with 'test', each of which contain one or more assertions such as is_deeply($got, $expected); and the test runner runs all the test* methods. It counts the number of test* methods for you. See Test::Class Test::Group :-) Adrian
Re: Unit vs. use case/functional testing
On 2 Mar 2007, at 22:53, James E Keenan wrote: Adrian Howard wrote: [snip] Adrian: How about posting this part on http://perl-qa.yi.org/ index.php/Main_Page? [snip] ObItsAWiki :-) Adrian
Re: a safer way to use no_plan?
On Sunday 04 March 2007 09:40, Shlomi Fish wrote:
My solution to this is:
...
What I do is add comments in a small domain-specific language ...
...
# TEST
is ($mystring, Hello, String is Hello);
# TEST*3
for my $i (0 .. 2)
{
ok ()
}
Wouldn't Test::Block be better than a home brewed system? Test::Block is not
perfect either (but what module is?); I specially miss the possibility to
have blocks inside block.
My 2 cents, Nadim.
Re: a safer way to use no_plan?
On Sunday 04 March 2007 09:40, Shlomi Fish wrote: My solution to this is: Of late, one solution I've used is just Ctrl-A and Ctrl-X in Vim, with some shortcuts: map silent ,at m` :silent /plan tests =CR3wC-A,/`` map silent ,rt m` :silent /plan tests =CR3wC-X,/`` This works well enough for simple test files. Note -- I always use plan() explicitly rather than specifying a plan as part of use Test::More. More often, I find myself creating some data structure to define test cases and then: plan tests = $fixed + $tests_per_case * @cases; Once I've defined the basic tests, I'm usually adding cases rather than changing the per-case test count, so the total test count takes care of itself. David
Re: a safer way to use no_plan?
David Golden wrote:
More often, I find myself creating some data structure to define test
cases and then:
plan tests = $fixed + $tests_per_case * @cases;
Once I've defined the basic tests, I'm usually adding cases rather
than changing the per-case test count, so the total test count takes
care of itself.
I often use this solution, and, for the test scripts that don't fit
this, I usually count tests by small blocs, letting Perl calculate
the total:
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
# etc
That's very simple and when adding new tests, I only have to update
the number of tests in the BEGIN that immediately precedes the
corresponding code.
--
Sébastien Aperghis-Tramoni
Close the world, txEn eht nepO.
Re: a safer way to use no_plan?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andy Lester wrote: 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! 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? - -- Tout n'y est pas parfait, mais on y honore certainement les jardiniers Dominique Quatravaux [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBReq8gfTYH7KfeIIFAQJJXgQAhUB16veolu17/SBExM8a5VnR1KkB/lW6 w0jJ1fyejFlbNXG+NQbdarbReRub0uX0VUzV2OnHp9dXn4n9gifeMFTGFIKPq3mv uS+aR3twnAg76HDCf6xAv8A7cBLNEROSCG/M3wpLFSzDlck9eTX3qmWvqQLVA16P s6kyIZ9pJss= =oP4M -END PGP SIGNATURE-
Re: Custom extensions to META.yml
In article [EMAIL PROTECTED], Ricardo SIGNES [EMAIL PROTECTED] wrote: * brian d foy [EMAIL PROTECTED] [2007-03-03T13:31:15] In article [EMAIL PROTECTED], Ricardo SIGNES [EMAIL PROTECTED] wrote: extensions: CPAN::Reporter: cc_author: 0 I think in some cases this might work, but I can imagine options that I'd want, such as cc_author, that future modules or tools might use. I won't know of them a priori, but it's likely that my answer to them will be the same. If you don't know that CPAN::Reporter uses extensions/CPAN::Reporter/cc_author, you won't know that it uses cc_author, either. I'm not talking about the particular field name, but the idea that I'd want to say in META.yml Don't send me mail, or whatever setting I want. Instead of having to disable (or enable) CC for every new tool, I'd want a setting that new tools could look at without me having to change the META.yml in all of my distributions then re-uploading them all.
Re: a safer way to use no_plan?
In article [EMAIL PROTECTED], Eric Wilhelm
[EMAIL PROTECTED] 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, but it may
be easier than counting tests. Thoughts?
You don't have to remember to put it at the bottom of the file if you
start with a template. :)
I run into problems where a loop runs fewer iterations than it should
but the test script otherwise runs to completion normally.
That's also a problem for the just run it and see argument. Sure, it
works for simple things, but when you get into hundreds or thousands of
tests, it's difficult to know if the humber you ran is the number you
were supposed to run. (This often is the case when I'm running
something that has several boundary conditions and I'm running every
combination of those. The factorials get big quick :)
Re: a safer way to use no_plan?
# 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 flies like an arrow, but fruit flies like a banana. --Groucho Marx --- http://scratchcomputing.com ---
Re: a safer way to use no_plan?
# 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 if...
use More::Tests;
use More::Tests n;
# paragraph of code with n tests
use More::Tests m;
# paragraph of code with m tests
no More::Tests; # :-D
--Eric
--
If the above message is encrypted and you have lost your pgp key, please
send a self-addressed, stamped lead box to the address below.
---
http://scratchcomputing.com
---
Re: a safer way to use no_plan?
# 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++;
}
is($counter, scalar(@foo), 'enough things');
I suppose a run-time goal adjustment and/or a for_ok([EMAIL PROTECTED], $sub)
would
be useful there?
I guess what I'm getting at is a goal-based plan. Aside from the (and I
do love to watch it spin) pretty progress output, the only real need
for a plan is to make sure that every test ran. I think that can
easily be done at run-time, which would make my life easier.
--Eric
--
I arise in the morning torn between a desire to improve the world and a
desire to enjoy the world. This makes it hard to plan the day.
--E.B. White
---
http://scratchcomputing.com
---
Re: a safer way to use no_plan?
Dominique Quatravaux wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andy Lester wrote: 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! 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? So what? Just skip the tests you can't execute under these conditions, it's precisely here to address such issues. -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: a safer way to use no_plan?
On Mar 4, 2007, at 6:33 AM, Dominique Quatravaux wrote:
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?
It's really not that hard. It's OK to declare a plan at runtime as
long as you declare your plan before you run your first test. If
your test program dies before that plan is emitted, the harness will
notice that zero tests ran and will complain accordingly.
For example, in CAM::PDF I have a number of test PDF documents that I
use to exercise the code, but I only ship a subset of them to CPAN
(the rest are too big or are license-incompatible). So, I do roughly
like so:
use Test::More; # plan declared at runtime below
my @test_docs = grep { -f $_ } 't/test1.pdf', 't/test2.pdf', ...;
plan tests = 12 + @test_docs * 20;
... run basic tests ...
for my $pdf_file (@test_docs) {
... run per-doc tests ...
}
Chris
--
Chris Dolan, Equilibrious LLC, http://equilibrious.net/
Public key: http://chrisdolan.net/public.key
vCard: http://chrisdolan.net/ChrisDolan.vcf
Re: a safer way to use no_plan?
* 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 like the number of parens in that.
Uh?
use Test::More 0 ? 'no_plan' : ( tests = 202 );
--
*AUTOLOAD=*_;sub _{s/(.*)::(.*)/print$2,(,$\/, )[defined wantarray]/e;$1}
Just-another-Perl-hack;
#Aristotle
Re: a safer way to use no_plan?
# 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 like the number of parens in that.
Uh?
use Test::More 0 ? 'no_plan' : ( tests = 202 );
Search pattern not terminated at uh.pl line 1.
I think you meant:
use Test::More 0 0 ? (tests = 202 ) : 'no_plan', {
q ( o ) ='
\_/ '
}
;
Then, to turn off the plan, I'll just do:
use constant X = 1;
use Test::More 0 X ? (tests = 202 ) : 'no_plan', {
q ( o ) ='
\_/ '
}
;
--Eric
--
use warnings;
use strict;
use constant X = 1;
use Test::More 0 X ? (tests = 42 ) : join('', 'n', map
{split} q ( o ) = qw/_ p l a n/), q(
\_/careful or you'll plan your eye out );
