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
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
Brilliant! (Score:1)
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 devel
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?
fast data loading (Score:1)
The MYSQL Hate is Strong in This One (Score:2)
I'm happy to say that I don't have to work with MySQL. The test suite for our Postgres-based app has several thousand tests grouped into directories. The database is re-initialised for each directory. The initialisation was based on replaying the original SQL/DDL followed by a bunch of schema patches, but that got really slow. We switched to using a dump of the DB and using pg_restore for each test directory and that was much faster. The next step was when someone realised that the Postgres createdb co
Compulsory first question (Score:1)
Are you using (MySQL) strict (mode)?