Re: a safer way to use no_plan?
# 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 that. The args are: use inc::testplan (, ); where is the battle-mode switch which is quite handily flipped with vim's 'r0' or 'r1' idiom (or Ctrl+a/Ctrl+x if you prefer.) In your case, you could: inc::testplan->import(1, 3 + @test_data * 3 ); I didn't bother wrapping plan() or adding much other interface as it is currently just an experiment in planning. Actually, if my test could figure out how many tests there will be so I got to watch that neato x/y progress output, I would never plan. http://svn.dotreader.com/svn/dotreader/trunk/inc/testplan.pm --Eric -- Entia non sunt multiplicanda praeter necessitatem. --Occam's Razor --- http://scratchcomputing.com ---
Re: a safer way to use no_plan?
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. -M --- Matisse Enzer <[EMAIL PROTECTED]> http://www.matisse.net/ - http://www.eigenstate.net/
Re: a safer way to use no_plan?
* Eric Wilhelm <[EMAIL PROTECTED]> [2007-03-03T21:59:32]
> In fact, so much eyewringing that I've taken to this lately:
>
> use inc::testplan(0,
> + 3 # use
> + 199 # those others
> );
What is that ... for?
I often do this:
use Test::More;
my @test_data = load_data('t/whatever.dat');
plan tests => 3 + @test_data * 3;
I'm not sure if your snippet is doing something else.
--
rjbs
Re: a safer way to use no_plan?
On Mar 3, 2007, at 8:59 PM, Eric Wilhelm wrote: Do you comment out the tests => foo and uncomment the no_plan line whenever you edit tests, or do you use a ternary and the r0/r1 vim idiom? Or do you just delete the 'tests' option and type no_plan longhand? I never use no_plan, except in the rare cases when a test can't reasonably know how much data it will be processing, as in a test of an arbitrary number of links on a web page. That means I don't use no_plan when editing tests. When I add a test, I go and add the tests, keeping a mental note of how many I've added, and then I go to the top of the file, and increment the number. I've added three tests? I increment the number by three. Sometimes I make a mistake. I'll add four tests but only add three to the count. I run prove, and oh no, the total is wrong. I svn diff to look to see that yes, I've actually added four, and I update the count by one more. I run prove again, and all is well. Commit. Repeat. It's really not that tough, and I don't mind the iteration. I think as programmers we get far too hung up on the idea of doing everything perfectly once. -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: a safer way to use no_plan?
# 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 wringing my hands, I just don't like step 3 of what could otherwise be a 2 step process. Further, it equates to steps 1 and 4 when adding more tests! Is it bad that I want it to work in a way that encourages me to add tests rather than punishing me for it? Do you comment out the tests => foo and uncomment the no_plan line whenever you edit tests, or do you use a ternary and the r0/r1 vim idiom? Or do you just delete the 'tests' option and type no_plan longhand? Seems like that would lead to at least some wristwringing. The ternary also leads to eyewringing in my case. In fact, so much eyewringing that I've taken to this lately: use inc::testplan(0, + 3 # use + 199 # those others ); ... done; --Eric -- To a database person, every nail looks like a thumb. --Jamie Zawinski --- http://scratchcomputing.com ---
Re: a safer way to use no_plan?
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 > > -- c > > Can't we use UNIVERSAL to work around these edge cases and throw lots of warnings? :-P -=Chris signature.asc Description: OpenPGP digital signature
Re: a safer way to use no_plan?
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 -- c
Re: a safer way to use no_plan?
On Mar 3, 2007, at 8:15 PM, Eric Wilhelm wrote: Yeah, you have to remember to put it at the end of the file, but it may be easier than counting tests. 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! All of this flapping about how maybe we should come up with some mechanisms to do test counting and blah blah blah is like buying a computer to store your recipes on instead of grandma's 3x5 index cards. They ain't sexy but they WORK. -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
a safer way to use no_plan?
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 no
code after tests_done()?
--Eric
--
The opinions expressed in this e-mail were randomly generated by
the computer and do not necessarily reflect the views of its owner.
--Management
---
http://scratchcomputing.com
---
Re: Custom extensions to META.yml
* 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. While you might implement the
same solution, I think it's less likely that you'll settle on the same name,
and thus benefit from happy accidents.
...but maybe the benefit of the middle-level namespace there isn't so great,
and extensions/cc_author is good enough. I suppose that the chance of
collision of extensions is fairly low. This could be helped by having CPANTS
(or something) produce a listing of extensions actually used in the CPAN's
code, so you could see what else uses what. Collisions would be reduced to
times when modules introducing new extensions are uploaded at the same time or
when one author is careless.
If a feature becomes useful enough to be part of the core spec, then tools need
to know to look for ->{extension}->{yourface} or for ->{yourface}, which is
also annoying.
A solution might be to use purpose-named namespaces owned by other individuals
to manage common configuration, including a generic per-tool namespace.
test_reporting:
also_cc: [ [EMAIL PROTECTED] ]
indexer:
index_all: 1
extensions:
Module::Started: { built_by: '1.602' }
This lets people who will probably have common needs work together (hopefully)
without the META.yml spec maintainer worry about much besides "does this
deserve a namespace" and lets everyone use a namespace for their own little
tools.
I don't know, I'm just throwing the idea out there. These things are always a
pain.
--
rjbs
Re: Custom extensions to META.yml
In article <[EMAIL PROTECTED]>, Ricardo SIGNES <[EMAIL PROTECTED]> wrote: > * David Golden <[EMAIL PROTECTED]> [2007-02-28T22:39:01] > > Is there a de facto standard for custom extensions to META.yml? (I > > didn't see one in the spec.) An example might be fields beginning > > with a capital letter or "X-foo" style extensions. E.g. > > Why not: > > 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. This proposal might be fine for some things that want to encapsulate some settings, but I predict there'll be some overlap if this ever gets popular.
