X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?p=catagits%2FCatalyst-Manual.git;a=blobdiff_plain;f=lib%2FCatalyst%2FManual%2FTutorial%2F08_Testing.pod;h=b555c2268c4a783b695a2d7418776b39fa403df3;hp=f21f5f6da1630dece21169d4122f17b927e830e8;hb=6c0a745efa9798edf8e9ac231027bfc997485054;hpb=da59dbea96454dbc53dc7bb5a813849bb35c6ab8 diff --git a/lib/Catalyst/Manual/Tutorial/08_Testing.pod b/lib/Catalyst/Manual/Tutorial/08_Testing.pod index f21f5f6..b555c22 100644 --- a/lib/Catalyst/Manual/Tutorial/08_Testing.pod +++ b/lib/Catalyst/Manual/Tutorial/08_Testing.pod @@ -132,29 +132,6 @@ environment variable. For example: $ CATALYST_DEBUG=0 prove -wl t -B Depending on the versions of various modules you have -installed, you might get some C warnings -- you can -ignore these. If you want to eliminate the warnings, you can -edit C to disable and then re-enable warnings -are the C line in C. -You can locate where C is located with the -following command (it's probably in a place similar to -C): - - perldoc -l Template::Base - -Edit the file and modify C to match: - - ... - { no strict qw( refs ); - # Disable warnings - no warnings; - $argnames = \@{"$class\::BASEARGS"} || [ ]; - # Turn warnings back on - use warnings; - } - ... - During the C and C tests, you might notice the C warning message. To execute the Pod-related tests, add C to the C @@ -299,7 +276,7 @@ editor and enter the following: # User 'test02' should not be able to add a book $ua2->get_ok("http://localhost/books/url_create/TestTitle2/2/5", "'test02' add"); $ua2->content_contains("Unauthorized!", "Check 'test02' cannot add"); - + done_testing; The C test cases uses copious comments to explain each step @@ -372,7 +349,11 @@ maintain both a "production database" for your live application and a "testing database" for your test cases. One advantage to L is that it runs your full application; however, this can complicate things when -you want to support multiple databases. One solution is to allow the +you want to support multiple databases. + +=head2 DATABASE CONFIG SWITCHING IN YOUR MODEL CLASS + +One solution is to allow the database specification to be overridden with an environment variable. For example, open C in your editor and change the C<__PACKAGE__-Econfig(...> declaration to resemble: @@ -380,10 +361,14 @@ change the C<__PACKAGE__-Econfig(...> declaration to resemble: my $dsn = $ENV{MYAPP_DSN} ||= 'dbi:SQLite:myapp.db'; __PACKAGE__->config( schema_class => 'MyApp::Schema', - + connect_info => { dsn => $dsn, - ... + user => '', + password => '', + on_connect_do => q{PRAGMA foreign_keys = ON}, + } + ); Then, when you run your test case, you can use commands such as: @@ -395,6 +380,50 @@ launch your normal application without the C environment variable defined, it will default to the same C as before. +=head2 DATABASE CONFIG SWITCHING USING MULTIPLE CONFIG FILES + +By utilizing Ls functionality for loading +multiple config files based on environment variables you can override your +default (production) database connection settings. + +Setting C<$ENV{ MYAPP_CONFIG_LOCAL_SUFFIX }> to 'testing' in your test script +results in loading of an additional config file named myapp_testing.conf after +myapp.conf which will override any parameters in myapp.conf. + +You should set the environment variable in the BEGIN block of your test script +to make sure it's set before your Catalyst application is started. + +The following is an example for a config and test script for a DBIx::Class +model named MyDB and a controller named Foo: + +myapp_testing.conf: + + + + dsn dbi:SQLite:myapp.db + + + + +t/controller_Foo.t: + + use strict; + use warnings; + use Test::More; + + BEGIN { + $ENV{ MYAPP_CONFIG_LOCAL_SUFFIX } = 'testing'; + } + + eval "use Test::WWW::Mechanize::Catalyst 'MyApp'"; + plan $@ + ? ( skip_all => 'Test::WWW::Mechanize::Catalyst required' ) + : ( tests => 2 ); + + ok( my $mech = Test::WWW::Mechanize::Catalyst->new, 'Created mech object' ); + + $mech->get_ok( 'http://localhost/foo' ); + =head1 AUTHOR