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.
  • We have a large test suite as well (almost 18,000 tests with a run time of about 54 minutes). I agree that running the whole thing is annoying. But it seems like you are spending too much time trying to speed up your test suite. As your application gets larger and more complex you will be guaranteed to add more tests (and even if you don't add any new features there are probably parts of the application that are undertested, so there's more tests there). Seems like a losing battle.

    Here at $work when a developer is working on a feature he should run the tests that are most relevant to that feature and nothing more. We have a smoke machine setup to constantly run against svn and report if there are any failures. So within an hour of checkin we find out if there are any problems.

    For the rare case where a certain feature is far reaching and changes lots of things about the code, then we have a branch for that and we can setup the smoker to run tests for that branch.

    Automated tests are nice, so why make humans run all of them by hand?

    • Here at $work when a developer is working on a feature he should run the tests that are most relevant to that feature and nothing more.

      Shameless self promotion, etc.

      Have you looked at Devel::CoverX::Covered [cpan.org]?

    • Seems like a losing battle.

      If you only get 3 - 5% improvements here and there, it probably is. (You have to work for those after the first few.)

      Ovid, I still wonder two things. What percentage of your tests eventually perform database work? How much data is in your testing database?