=head1 Testing difficult-to-test database models
-In this article we're going to describe a technique for testing database
-heavy web applications using either a temporary testing database, or using
-the DSN defined in your catalyst application depending on the presence of
-an envoronmnet variable. If the latter we will not delete the contents of
-the database afterwards because this workflow suggests that we will want to
-poke around our application manually with the application in a known state.
-
-Basically, providing automated testing of complex databases is a pain. For
+In this article we're going to describe a technique for testing database-heavy
+web applications using either a temporary testing database, or using the DSN
+defined in your Catalyst application depending on the presence of an
+environment variable. If the latter, we will not delete the contents of the
+database afterwards, because this workflow suggests that we will want to poke
+around our application manually with the application in a known state.
+
+Basically, providing automated testing of complex databases is a pain. For
generic type functions (e.g. the development of libraries rather than
applications), mock objects (objects that mimic the interface of a real
-object) are useful for unit testing. But in the running on the seat of
-your pants development style that commercial web applications often
-require, small changes to functionality can wreack havock with your mock
+object) are useful for unit testing. But in the running on the
+seat-of-your-pants development style that commercial web applications often
+require, small changes to functionality can wreak havoc with your mock
objects, and they rapidly become more trouble than they're worth.
Which is where L<Test::DBIx::Class> comes in. The rest of this article
my $mech = Test::WWW::Mechanize::Catalyst->new;
$mech->get('whatever');
- ### etc
+ ### etc.
And the database operations should all really happen, but to a temporary
database that gets deleted at the end of the run. This is especially
useful if you have lots of tests that all need a pristine copy of the
database with their own fixtures, as it means you can speed things up by
-running in parallell (e.g. to run 3 tests in parallell run C< prove -l -j 3
+running in parallel (e.g. to run 3 tests in parallel run C< prove -l -j 3
t >).
-=head2 OK Good. This time let's optionally override the temporary database
+=head2 OK Good. This time let's optionally override the temporary database
with the developer's DSN
One development style which works fairly well is to write tests to run on
the development database, and then have a play around at the end of the
-test run either with the perl debugger or using the built in development
+test run either with the Perl debugger or using the built in development
server. However this means that one can't always rely on having a
temporary testing database for running tests.
have a process whereby your database schemas are signed off (and likely
modified) by a DBA you're likely going to want the master copy of your
database in SQL rather than DBIC files. Likewise if you have evil business
-logic that's best encapsulated in a database trigger you'll likely hit the
+logic that's best encapsulated in a database trigger, you'll likely hit the
same type of problems.
-Given we're using a postgresql database in this instance, we need some pg
-specific code to spin up either a temporary database or to repopulate the
-development database. So to complement
-L<Test::DBIx::Class::SchemaManager::Trait::Testpostgresql>, we've written
-our own internal C<Test::DBIx::Class::SchemaManager::Trait::DeploySQL>
-class that should be kept in C<
-t/lib/Test/DBIx/Class/SchemaManager/Trait/DeploySQL.pm > in your app's
-directory tree. It's possible this could be released as a CPAN module one
-day, but at this stage we suspect that every development situation is
-sufficiently different that it's probably better just to leave these
-particular bits of wheel lying around for other people to adapt,
-rather than offering an explicit canned solution that's supposed to work
-for everybody.
-
-Meanwhile here's what we have for our postgresql database populated by sql statements:
+Given we're using a Postgres database in this instance, we need some
+Pg-specific code to spin up either a temporary database or to repopulate the
+development database. So to complement
+L<Test::DBIx::Class::SchemaManager::Trait::Testpostgresql>, we've written our
+own internal C<Test::DBIx::Class::SchemaManager::Trait::DeploySQL> class that
+should be kept in C< t/lib/Test/DBIx/Class/SchemaManager/Trait/DeploySQL.pm >
+in your app's directory tree. It's possible this could be released as a CPAN
+module one day, but at this stage we suspect that every development situation
+is sufficiently different that it's probably better just to leave these
+particular bits of wheel lying around for other people to adapt, rather than
+offering an explicit canned solution that's supposed to work for everybody.
+
+Meanwhile here's what we have for our Postgres database populated by SQL statements:
use Moose::Role;
use MyApp;
projects / catagits/Catalyst-Manual-Monthly.git / commitdiff