[Dbix-class] Dumping fixtures and loading in test script

[David Cantrell]

On Mon, Nov 11, 2013 at 02:29:01PM -0500, Rob Kinyon wrote:

> This makes for poor testability. Otherwise, when you have a schema
> change, you either:
> 1. Force everyone sharing the same developer instance to immediately
> have to deal with your schema changes

Having devs share a database will never* work, because different
developers may require different incompatible versions of the schema.
eg, the developer working on a future version of your product, and the
developer backporting a bugfix to an old version that some customers are
still paying for support on. Then you've also got problems like how to
test that your code does the right thing with an empty table, when other
devs are concurrently running tests that require having data in the
table.

To do anything other than have one database per developer is insane.

Of course, this also means that you ought to have scripts that will run
your tests against a clone of your database (and, indeed, a clone of
your code and config). Why? So that you can run all the tests against
one branch while you start work on another.

Here we have such a script that takes args like:

$ scripts/isolated.pl \
    --cleanup \
    --cover --cover_report_dir=$HOME/coverage \
    prove -vm t

It clones the entire environment and then runs whatever the hell you
want against the clone. That could be running the test suite, or it
could be starting an instance of the app that you can then interact
with, or load testing, or ... and also has switches to turn on/off
Devel::Cover. Finally, it can clean up the clone on exit or leave it
hanging around for debuggery.

* sweeping generalisations never work either

-- 
David Cantrell | Nth greatest programmer in the world

Never attribute to malice that which can be explained by stupidity
    -- Hanlon's Razor

Stupidity maintained long enough is a form of malice
    -- Richard Bos's corollary