in reply to Re^2: How can I write Test::Finished? (auto count)
in thread How can I write Test::Finished?

Well, you could use it how you like. I'd run "make plan" every time I released a new version of the module. You could even make "make dist" run "make plan" (for your modules).

If I'm about to make a lot of incremental changes to some test plans, then I could remove the number from the "use Test::AutoPlan" line to revert to plan-less testing.

I'd think even you would do "make test" every time you added new tests so I'm not sure why replacing that with "make plan; make test" (or perhaps just "make plan test") is such a hardship for you. I'd think the "work" is doing the counting. If you can't handle typing those few extra characters, then I don't know how you managed to produce a module in the first place. (:

[ Update: Actually, "make plan" should tell you if any tests failed so you could just always use "make plan" instead of "make test" and fool people into thinking that you use plans when you never do. If you have "make plan" be smart enough to not update test files if they already report the correct plan number, then this seems like it might even be little enough work / change for you (if I can be so presumptuous as to make such a guess). ]

But it sounds like you don't care at all about the types of failures that plans are meant to catch, so perhaps you should just add: 

ok( 1, "NO, I don't *WANT* a plan" )
    if rand() < 0.5;

[download]

to the end of all of your test files to prevent those annoying patches from coming it.

- tye        

Replies are listed 'Best First'.
Re^4: How can I write Test::Finished? (auto count)
by samtregar (Abbot) on Jun 22, 2004 at 01:02 UTC
    I'm not sure why replacing that with "make plan; make test" (or perhaps just "make plan test") is such a hardship for you.

    It's a hardship because I'll forget to do it. My fingers know how to type 'make test' all by themselves; they don't even ask my spinal column for guidence.

    But it sounds like to don't care at all about the types of failures that plans are meant to catch

    That's almost true. I certainly don't care enough to maintain a magic number at the top of all my test files. But I do care enough to bang out a module that I can add once and forget about. It sounds like some combination of a source filter and fork() will do the trick, so I think I'll give that a try.

    -sam

[reply]
      But I do care enough to bang out a module that I can add once and forget about. It sounds like some combination of a source filter and fork() will do the trick

      Note that that won't catch all of the problems that test plans catch. I think it catches the least likely of those problems [some code causing an early exit(0)].

      - tye        

[reply]
        It will catch any problem that causes the test script to not run to completion. If you're thinking about problems with shortened loops, I generally already test them with something like:

           is($loop_count, 10, "Loop ran 10 times");

        That's a case of manual counting that makes sense to me, and it's close enough to the code it references to be easy to maintain. Plus, when it fails I know exactly which loop ran short. When you get a failure from a global count you don't have a clue as to where in the test file to look.

        But I'm just guessing here. What problems are you suggesting?

        -sam

[reply]
[d/l]

In Section Seekers of Perl Wisdom