Stories
Slash Boxes
Comments
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

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • 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.

    • 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