NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
an endless discussion thread about what features to include.
-- Jarkko Hietaniemi
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
Making it "less wrong"? (Score:1)
It sounds like your version control system could help you here. It should be easy to use Devel::Cover to generate a source file -> relevant test mapping. From there, you can see which files are affected by a merge. Then, you can compute a minimum set of relevant "slow" tests to run. This should prevent the merger from having to run all the tests, and save him some time.
Obviously this could go wrong in a number of ways, but it might be helpful anyway.
Reply to This
Re: (Score:2)
Devel::Cover is a wonderful tool, but we have a lot of trouble using it. Our test suite is slow enough, but with Devel::Cover, it can only be run once, and that's an overnight run (7 to 10 hours).
What this means is that we can only run it on trunk, but we need it run on our branches. Since they change, add and (sometimes) delete tests, we've no real guarantee of which tests from a branch should be run, thus putting us back at square run.
And for extra credit, create a multi-user development environment wh
Re: (Score:2)
thus putting us back at square run
WTF? "Square one".
Re: (Score:1)
Devel::CoverX::Covered [cpan.org] does the mapping (which turned out to be far from "easy").
But it doesn't quite solve the problem.
Which isn't really a technical problem anyway. People just needs to run the tests.
Re: (Score:2)
Except it is a technical problem because the tests take 40 minutes. That's a lot of developer time wasted.
Re: (Score:2)
Yes, this is a huge problem. It's also a hell of a lot faster than it was [slideshare.net]. Huge amounts of work went into speeding up that test suite and Test::Aggregate [cpan.org] is one of the results.