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.
  • The longest suite I've worked with took about an hour and a half to complete. Regrettably, it was written with a bespoke (and broken) test harness.

    Why does your current test suite take so long to run? There are numerous strategies which can generally be applied to mitigate long test suite run times (or are you not bothered by this?).

    • In Perl::Dist(::Strawberry) I build Perl from scratch, about 7 times.

      Across all of them, I also install about 200+ CPAN modules...

      And unfortunately, none of it knows when to test in parallel on it's own, so much of my the power of my quad-core machine is wasted.

      At work, much of the extra work is necessary, because the application is ENORMOUS (250k source lines of code) with lots of lots of potential variation and state.

      Before every single test script, we kill and rebuilt users from scratch. Some test direct

      • For the long setup time, have you considered creating a set of general test data that can be used for many of the tests?

        If you can do that, then maybe you can cache the setup of it and avoid long processing time just to get to the correct state.

        So the app code is used to move the app to the correct state only once per test suite run, or even outside of the test run. Once that is done, make a snapshot of it that can be restored quicker for each test.

        This is something we haven't done yet, but I'm thinking of