Greg Sabino Mullane wrote:
> On Fri, 2007-09-28 at 17:09 -0700, Michael G Schwern wrote:
>
>>> It's also nice to see how far along we are with a running
>>> tally, when I check back in on the running tests.
>
>> How do you accomplish that?
>
> Not sure what you mean. Toggle back to the terminal window, generally.
> Due to the nature of the beast (database replication), the full tests
> generally take about 7 minutes to complete.
Sorry, I was asking how you run only parts of the test suite which you
answered below.
>> Why do you do that? That you have to "check back" indicates that
>> an individual test file takes a long time to run. The desire to
>> run only some of the tests in a file is usually a red flag
>> that there's too many tests in each file.
>>
>> Could you simply break the test up into individual files that
>> you could then run individually?
>
> I could, but it gets hairy as there are lots of interconnected
> subroutines and common code and it's far easier to keep it in a single
> file. Using separate test files is my natural inclination, and I tried
> it that way at first, but in this particular module's case, it made my
> life easier to have it all in one.
Without seeing the details I really can't make a judgment call, but it smells
an awful lot like it should be detangled and the common code placed into a
t/lib helper library. Every time I've piled code into one file in order to
take advantage of special setup code and custom testing functions the test
just kept getting hairier and hairier and more deeply interconnected.
Breaking it up both simplifies things and it makes it easier to write more
tests since the special code is available everywhere.
In short, it sounds like you're bending over backwards to support a hairball
rather than untangling the hairball.
> Toggling a few boolean values at the
> top of the file is easier than trying to keep track of which test files
> to run from the command line as well.
$Test_Something = 1;
t/something.t
Pretty much saying the same thing. With Module::Build it's trivial to write
up special actions to test multiple files in sets.
sub ACTION_testfoo {
my $self = shift;
$self->{properties}{test_files} = [qw(t/foo.t t/bar.t)];
return $self->ACTION_test;
}
That it's possible to flip booleans to turn on and off certain parts of the
test tells me it's already internally broken up and should be a fairly rote
maneuver to split it into multiple tests.
>>> You mean passing in the raw keys and values? Ick.
>
>> Don't say "ick", say why. Don't feel, think. [1] Does it just
>> *feel* wrong or do you know why it actually *is* wrong?
>
> Oh, I know why, I just didn't think I needed to spell it out to this
> crowd. :) The problem is that when a user invariably forgets to put in a
> hash value, it's more helpful if perl complains about an odd number of
> elements at the spot where the user is calling count_tests, not buried
> inside of count_tests itself. It also helps the reader see that the
> subroutine expects a bunch of key/value pairs, not just a list:
>
> foobar($alpha, $beta); ## List? Hash? Positions matter? Are they
> related?
>
> foobar({$alpha => $beta}); ## No ambiguity
foobar( $alpha => $beta ); ## No ambiguity either
Also not possible to forget a value if you use arrow.
But ok, I asked for a reason and I got one. :)
--
Hating the web since 1994.
