X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?p=catagits%2FCatalyst-Manual.git;a=blobdiff_plain;f=lib%2FCatalyst%2FManual%2FTutorial%2FTesting.pod;h=04c08ab14a5f91fc52a33472bced1243fd9a4e23;hp=f3b2b6412e68a293ba60971f1dea7e2f5762d3ac;hb=3b1fa91be1d89d2297aa9e8e83462344d9cd9820;hpb=5e6026272f809951ac22fae43b73d2c1dc79c7fc diff --git a/lib/Catalyst/Manual/Tutorial/Testing.pod b/lib/Catalyst/Manual/Tutorial/Testing.pod index f3b2b64..04c08ab 100644 --- a/lib/Catalyst/Manual/Tutorial/Testing.pod +++ b/lib/Catalyst/Manual/Tutorial/Testing.pod @@ -1,11 +1,11 @@ =head1 NAME -Catalyst::Manual::Tutorial::Testing - Catalyst Tutorial - Part 7: Testing +Catalyst::Manual::Tutorial::Testing - Catalyst Tutorial - Chapter 8: Testing =head1 OVERVIEW -This is B for the Catalyst tutorial. +This is B for the Catalyst tutorial. L @@ -21,46 +21,56 @@ L =item 3 -L +L =item 4 -L +L =item 5 -L +L =item 6 -L +L =item 7 -B +L =item 8 -L +B =item 9 +L + +=item 10 + L =back + =head1 DESCRIPTION -You may have noticed that the Catalyst Helper scripts automatically -create basic C<.t> test scripts under the C directory. This part of -the tutorial briefly looks at how these tests can be used to not only -ensure that your application is working correctly at the present time, -but also provide automated regression testing as you upgrade various -pieces of your application over time. +You may have noticed that the Catalyst Helper scripts automatically +create basic C<.t> test scripts under the C directory. This +chapter of the tutorial briefly looks at how these tests can be used +not only to ensure that your application is working correctly at the +present time, but also provide automated regression testing as you +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. + +For an excellent introduction to learning the many benefits of testing +your Perl applications and modules, you might want to read 'Perl Testing: +A Developer's Notebook' by Ian Langworth and chromatic. -You can checkout the source code for this example from the catalyst -subversion repository as per the instructions in -L =head1 RUNNING THE "CANNED" CATALYST TESTS @@ -71,9 +81,20 @@ directory, enter: $ prove --lib lib t -The redirection used by the Authentication plugins will cause the -default C to fail. You can fix this by changing the line in -C that read: +There will be a lot of output because we have the C<-Debug> flag +enabled in C (see the C tip below for +a quick and easy way to reduce the clutter). Look for lines like this +for errors: + + # Failed test 'Request should succeed' + # at t/controller_Books.t line 8. + # Looks like you failed 1 test of 3. + +The redirection used by the Authentication plugins will cause several +failures in the default tests. You can fix this by making the following +changes: + +1) Change the line in C that reads: ok( request('/')->is_success, 'Request should succeed' ); @@ -81,13 +102,25 @@ to: ok( request('/login')->is_success, 'Request should succeed' ); -So that a redirect is not necessary. Also, the C -and C default test cases will fail because of the -authorization. You can delete these two files to prevent false error -messages: +2) Change the line in C that reads: - $ rm t/controller_Books.t - $ rm t/controller_Logout.t + ok( request('/logout')->is_success, 'Request should succeed' ); + +to: + + ok( request('/logout')->is_redirect, 'Request should succeed' ); + +3) Change the line in C that reads: + + ok( request('/books')->is_success, 'Request should succeed' ); + +to: + + ok( request('/books')->is_redirect, 'Request should succeed' ); + +4) Add the following statement to the top of C: + + use MyApp; As you can see in the C command line above, the C<--lib> option is used to set the location of the Catalyst C directory. With this @@ -99,6 +132,29 @@ 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; + } + ... + During the C and C tests, you might notice the C warning message. To execute the Pod-related tests, add C to the C @@ -115,6 +171,7 @@ prints the name of each test case as it is being run: $ CATALYST_DEBUG=0 TEST_POD=1 prove --lib lib -v t + =head1 RUNNING A SINGLE TEST You can also run a single script by appending its name to the C @@ -122,11 +179,12 @@ command. For example: $ CATALYST_DEBUG=0 prove --lib lib t/01app.t -Note that you can also run tests directly from Perl without C. +Also note that you can also run tests directly from Perl without C. For example: $ CATALYST_DEBUG=0 perl -Ilib t/01app.t + =head1 ADDING YOUR OWN TEST SCRIPT Although the Catalyst helper scripts provide a basic level of checks @@ -179,12 +237,7 @@ 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'"); - # Use the form for user 'test02'; note there is no description here - $ua2->submit_form( - fields => { - username => 'test02', - password => 'mypass', - }); + $ua1->get_ok("http://localhost/login?username=test02&password=mypass", "Login 'test02'"); # 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; @@ -193,7 +246,7 @@ editor and enter the following: "Check we ARE logged in" ) for $ua1, $ua2; # 'Click' the 'Logout' link (see also 'text_regex' and 'url_regex' options) - $_->follow_link_ok({n => 1}, "Logout via first link on page") for $ua1, $ua2; + $_->follow_link_ok({n => 4}, "Logout via first link on page") for $ua1, $ua2; $_->title_is("Login", "Check for login title") for $ua1, $ua2; $_->content_contains("You need to log in to use this application", "Check we are NOT logged in") for $ua1, $ua2; @@ -210,7 +263,7 @@ editor and enter the following: $_->content_contains("Book List", "Check for book list title") for $ua1, $ua2; # Make sure the appropriate logout buttons are displayed - $_->content_contains("/logout\">Logout", + $_->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"); @@ -270,10 +323,10 @@ or $ DBIC_TRACE=0 CATALYST_DEBUG=0 prove --lib lib -v t/live_app01.t -Experiment with the C, C -and C<-v> settings. If you find that there are errors, use the -techniques discussed in the "Catalyst Debugging" section (Part 6) to -isolate and fix any problems. +Experiment with the C, C and C<-v> +settings. If you find that there are errors, use the techniques +discussed in the "Catalyst Debugging" section (Chapter 7) to isolate +and fix any problems. If you want to run the test case under the Perl interactive debugger, try a command such as: @@ -298,10 +351,16 @@ lies. A simple technique that can be used in such situations is to temporarily insert a line similar to the following right after the failed test: - warn $ua1->content; + diag $ua1->content; This will cause the full HTML returned by the request to be displayed. +Another approach to see the full HTML content at the failure point in +a series of tests would be to insert a "C<$DB::single=1;> right above +the location of the failure and run the test under the perl debugger +(with C<-d>) as shown above. Then you can use the debugger to explore +the state of the application right before or after the failure. + =head1 SUPPORTING BOTH PRODUCTION AND TEST DATABASES @@ -312,18 +371,14 @@ 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 database specification to be overridden with an environment variable. -For example, open C in your editor and +For example, open C in your editor and change the C<__PACKAGE__-Econfig(...> declaration to resemble: my $dsn = $ENV{MYAPP_DSN} ||= 'dbi:SQLite:myapp.db'; __PACKAGE__->config( - schema_class => 'MyAppDB', + schema_class => 'MyApp::Schema', connect_info => [ $dsn, - '', - '', - { AutoCommit => 1 }, - ], ); @@ -344,8 +399,8 @@ 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. +L. -Copyright 2006, Kennedy Clark, under Creative Commons License -(L). +Copyright 2006-2008, Kennedy Clark, under Creative Commons License +(L).