X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=blobdiff_plain;f=lib%2FCatalyst%2FManual%2FTutorial%2F08_Testing.pod;h=b803acda307838b81e5781f7fc85e83f469aacd9;hb=22fe0f18ac89a984b2a27ff0eb146f485cfb9a8c;hp=c8671c0b4e958c198d025bc5366e9239dd82fd25;hpb=3ab6187c1a123983b6ae29e57f543328ce15755c;p=catagits%2FCatalyst-Manual.git diff --git a/lib/Catalyst/Manual/Tutorial/08_Testing.pod b/lib/Catalyst/Manual/Tutorial/08_Testing.pod index c8671c0..b803acd 100644 --- a/lib/Catalyst/Manual/Tutorial/08_Testing.pod +++ b/lib/Catalyst/Manual/Tutorial/08_Testing.pod @@ -65,7 +65,7 @@ upgrade various pieces of your application over time. You can check out the source code for this example from the Catalyst Subversion repository as per the instructions in -L. +L. For an excellent introduction to learning the many benefits of testing your Perl applications and modules, you might want to read 'Perl Testing: @@ -79,7 +79,7 @@ C and C), but one of the easiest is with the C command. For example, to run all of the tests in the C directory, enter: - $ prove --lib lib t + $ prove -wl t There will be a lot of output because we have the C<-Debug> flag enabled in C (see the C tip below for @@ -130,37 +130,14 @@ Although you can edit the C to comment out the C<-Debug> plugin, it's generally easier to simply set the C environment variable. For example: - $ CATALYST_DEBUG=0 prove --lib lib 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; - } - ... + $ CATALYST_DEBUG=0 prove -wl t During the C and C tests, you might notice the C warning message. To execute the Pod-related tests, add C to the C command: - $ CATALYST_DEBUG=0 TEST_POD=1 prove --lib lib t + $ CATALYST_DEBUG=0 TEST_POD=1 prove -wl t If you omitted the Pod comments from any of the methods that were inserted, you might have to go back and fix them to get these tests to @@ -169,7 +146,7 @@ pass. :-) Another useful option is the C (C<-v>) option to C. It prints the name of each test case as it is being run: - $ CATALYST_DEBUG=0 TEST_POD=1 prove --lib lib -v t + $ CATALYST_DEBUG=0 TEST_POD=1 prove -vwl t =head1 RUNNING A SINGLE TEST @@ -177,12 +154,12 @@ prints the name of each test case as it is being run: You can also run a single script by appending its name to the C command. For example: - $ CATALYST_DEBUG=0 prove --lib lib t/01app.t + $ CATALYST_DEBUG=0 prove -wl t/01app.t Also note that you can also run tests directly from Perl without C. For example: - $ CATALYST_DEBUG=0 perl -Ilib t/01app.t + $ CATALYST_DEBUG=0 perl -w -Ilib t/01app.t =head1 ADDING YOUR OWN TEST SCRIPT @@ -190,10 +167,10 @@ For example: Although the Catalyst helper scripts provide a basic level of checks "for free," testing can become significantly more helpful when you write your own script to exercise the various parts of your application. The -L module +L module is very popular for writing these sorts of test cases. This module -extends L (and therefore -L) to allow you to automate the action of +extends L (and therefore +L) to allow you to automate the action of a user "clicking around" inside your application. It gives you all the benefits of testing on a live system without the messiness of having to use an actual web server, and a real person to do the clicking. @@ -205,19 +182,13 @@ editor and enter the following: use strict; use warnings; - - # Load testing framework and use 'no_plan' to dynamically pick up - # all tests. Better to replace "'no_plan'" with "tests => 30" so it - # knows exactly how many tests need to be run (and will tell you if - # not), but 'no_plan' is nice for quick & dirty tests - - use Test::More 'no_plan'; + use Test::More; # Need to specify the name of your app as arg on next line # Can also do: # use Test::WWW::Mechanize::Catalyst "MyApp"; - use ok "Test::WWW::Mechanize::Catalyst" => "MyApp"; + BEGIN { use_ok("Test::WWW::Mechanize::Catalyst" => "MyApp") } # Create two 'user agents' to simulate two different users ('test01' & 'test02') my $ua1 = Test::WWW::Mechanize::Catalyst->new; @@ -237,7 +208,12 @@ editor and enter the following: # Log in as each user # Specify username and password on the URL $ua1->get_ok("http://localhost/login?username=test01&password=mypass", "Login 'test01'"); - $ua1->get_ok("http://localhost/login?username=test02&password=mypass", "Login 'test02'"); + # Could make user2 like user1 above, but use the form to show another way + $ua2->submit_form( + fields => { + username => 'test02', + password => 'mypass', + }); # Go back to the login page and it should show that we are already logged in $_->get_ok("http://localhost/login", "Return to '/login'") for $ua1, $ua2; @@ -265,8 +241,10 @@ editor and enter the following: # Make sure the appropriate logout buttons are displayed $_->content_contains("/logout\">User Logout", "Both users should have a 'User Logout'") for $ua1, $ua2; - $ua1->content_contains("/books/form_create\">Create", - "Only 'test01' should have a create link"); + $ua1->content_contains("/books/form_create\">Admin Create", + "'test01' should have a create link"); + $ua2->content_lacks("/books/form_create\">Admin Create", + "'test02' should NOT have a create link"); $ua1->get_ok("http://localhost/books/list", "View book list as 'test01'"); @@ -298,17 +276,19 @@ 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 of the process. In addition to the techniques shown here, there are a variety of other methods available in -L (for +L (for example, regex-based matching). Consult the documentation for more detail. B: For I vs. the "full application tests" approach used -by L, see -L. +by L, see +L. B The test script does not test the C and C actions. That is left as an exercise for the reader @@ -317,11 +297,11 @@ template). To run the new test script, use a command such as: - $ CATALYST_DEBUG=0 prove --lib lib -v t/live_app01.t + $ CATALYST_DEBUG=0 prove -vwl t/live_app01.t or - $ DBIC_TRACE=0 CATALYST_DEBUG=0 prove --lib lib -v t/live_app01.t + $ DBIC_TRACE=0 CATALYST_DEBUG=0 prove -vwl t/live_app01.t Experiment with the C, C and C<-v> settings. If you find that there are errors, use the techniques @@ -367,9 +347,13 @@ the state of the application right before or after the failure. You may wish to leverage the techniques discussed in this tutorial to maintain both a "production database" for your live application and a "testing database" for your test cases. One advantage to -L is that +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: @@ -377,30 +361,81 @@ 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, - ], + + 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: $ cp myapp.db myappTEST.db - $ CATALYST_DEBUG=0 MYAPP_DSN="dbi:SQLite:myappTEST.db" prove --lib lib -v t/live_app01.t + $ CATALYST_DEBUG=0 MYAPP_DSN="dbi:SQLite:myappTEST.db" prove -vwl t/live_app01.t This will modify the DSN only while the test case is running. If you 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 Kennedy Clark, C -Please report any errors, issues or suggestions to the author. The -most recent version of the Catalyst Tutorial can be found at -L. +Feel free to contact the author for any errors or suggestions, but the +best way to report issues is via the CPAN RT Bug system at +. -Copyright 2006-2008, Kennedy Clark, under Creative Commons License -(L). +The most recent version of the Catalyst Tutorial can be found at +L. +Copyright 2006-2010, Kennedy Clark, under the +Creative Commons Attribution Share-Alike License Version 3.0 +(L).