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
--Larry Wall in perl.c from the perl source code
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
Still wondering why... (Score:1)
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?
Reply to This
Re: (Score:1)
Shameless self promotion, etc.
Have you looked at Devel::CoverX::Covered [cpan.org]?
Re: (Score:1)
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?