<flogging the point>thats precisely what -v does currently, same convenience argument applies.
I see a difference in that
prove -v
is shorthand for
TEST_VERBOSE=1 make test
I thought it was
"HARNESS_VERBOSE"
If true, Test::Harness will output the verbose results
of running its tests. Setting $Test::Harness::verbose
will override this, or you can use the "-v" switch in
the prove utility.which suggests that all of keys %ENV is a large namespace to remember,
and behavior-magic happens from somewhere 'distant' from user head-space.
command-line args are a bit 'closer', and are more likely to come with -help.
</flogging>
I'm not against the idea. Just not sure about the implementation.
There is no implementation - Im *not* proposing any of the OptreeCheck apparatus, so much as showing what might happen if no 'best way' is codified ;-)
If instead you meant 'how one might do it', I had a quick enough look to shoot from the hip:
runtests(@tests) could become runtests ($@), but $ is an optional arrayref. Kinda clumsy, but backward compatible, and no out-of-band @PASS_ARGV ugliness.
In fact, any arrayref embedded into the @tests could reasonably be construed to be a set of cmdline options for use with the following tests
Yes - but 1st let me fish for argument use-cases in tests.Whyncha write the manpage docs for how it'll work? That'll give us something more definite to base it on.
xoa
Its worth seeing if theres any latent pattern of usages, and to devise something
that interworks with all / max-consistent-set of them.
some greppings (on core, not cpan): 'torture' and 'ARGV'
make torturetest
t/harness:19:if ($ARGV[0] eq '-torture') {
t/harness:21: $torture = 1;
t/harness:67: push @tests, <japh/*.t> if $torture;
./t/pod/multiline_items.t:9:my %options = map { $_ => 1 } @ARGV; ## convert cmdline to options-hash
./t/pod/emptycmd.t:9:my %options = map { $_ => 1 } @ARGV; ## convert cmdline to options-hash
./t/pod/for.t:9:my %options = map { $_ => 1 } @ARGV; ## convert cmdline to options-hash
./t/pod/headings.t:9:my %options = map { $_ => 1 } @ARGV; ## convert cmdline to options-hash
./t/pod/include.t:9:my %options = map { $_ => 1 } @ARGV; ## convert cmdline to options-hash
./t/pod/included.t:9:my %options = map { $_ => 1 } @ARGV; ## convert cmdline to options-hash
./t/pod/lref.t:9:my %options = map { $_ => 1 } @ARGV; ## convert cmdline to options-hash
./t/pod/nested_items.t:9:my %options = map { $_ => 1 } @ARGV; ## convert cmdline to options-hash
./t/pod/nested_seqs.t:9:my %options = map { $_ => 1 } @ARGV; ## convert cmdline to options-hash
./t/pod/oneline_cmds.t:9:my %options = map { $_ => 1 } @ARGV; ## convert cmdline to options-hash
./t/pod/pod2usage.t:9:my %options = map { $_ => 1 } @ARGV; ## convert cmdline to options-hash
./t/pod/poderrs.t:9:my %options = map { $_ => 1 } @ARGV; ## convert cmdline to options-hash
./t/pod/podselect.t:9:my %options = map { $_ => 1 } @ARGV; ## convert cmdline to options-hash
./t/pod/special_seqs.t:9:my %options = map { $_ => 1 } @ARGV; ## convert cmdline to options-hash
from these, I can glean a couple facts/suppositions/innuendos:
both arguments and -options are used to control core test behavior
not that many torture tests exist
both pod and OptreeCheck turn booleans into mapped options.
Any other cases where tests operate according to @ARGV, use-cases, examples from CPAN, out there to consider ??
Imp-Notes:
its possible to do this passthru transparently: Configuring Getopt::Long - pass_through (default: disabled)
but its probly unwise to broaden the option interface that wide, pitching errors to user via getopt is a good thing.
it might be better to handle options and args separately;
prove --pass_arg testmode=cross --pass_arg selftest ext/B/t/optree_*.t prove --pass_opt v some_test_with_its_own_v_option.t
the latter would prepend '-' to collected @PT_OPTS, thus avoiding confusion wrt who should get the '-v' that would be needed otherwize.
thanks Andy, jimc
