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.

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

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