X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=blobdiff_plain;f=lib%2FCatalyst%2FManual%2FTutorial%2FTesting.pod;h=0ff79165b619bc41833844b6b1f2c50de35ccf05;hb=c9b77c06a0de97f1d6e9a66091e693a637578357;hp=c8ea93094bf2f527aa2118ec20f0833fb9131a03;hpb=64ccd8a8bfbc16276c044c94702b1440c2897695;p=catagits%2FCatalyst-Runtime.git diff --git a/lib/Catalyst/Manual/Tutorial/Testing.pod b/lib/Catalyst/Manual/Tutorial/Testing.pod index c8ea930..0ff7916 100644 --- a/lib/Catalyst/Manual/Tutorial/Testing.pod +++ b/lib/Catalyst/Manual/Tutorial/Testing.pod @@ -2,8 +2,6 @@ Catalyst::Manual::Tutorial::Testing - Catalyst Tutorial - Part 7: Testing - - =head1 OVERVIEW This is B for the Catalyst tutorial. @@ -46,35 +44,30 @@ L =item 9 -L +L =back - - =head1 DESCRIPTION - You may have noticed that the Catalyst Helper scripts automatically -create 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. +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. B: Note that all of the code for this part of the tutorial can be pulled from the Catalyst Subversion repository in one step with the following command: - svn checkout http://dev.catalyst.perl.org/repos/Catalyst/trunk/examples/Tutorial@### - IMPORTANT: Does not work yet. Will be completed for final version. - + svn co http://dev.catalyst.perl.org/repos/Catalyst/tags/examples/Tutorial/MyApp/5.7/Testing MyApp =head1 RUNNING THE "CANNED" CATALYST TESTS There are a variety of ways to run Catalyst and Perl tests (for example, -C and C, but one of the easiest is with the +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: @@ -106,7 +99,7 @@ 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 + $ CATALYST_DEBUG=0 prove --lib lib t During the C and C tests, you might notice the C warning message. To @@ -124,8 +117,6 @@ 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 @@ -138,19 +129,18 @@ 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 "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 -is very popular for writing these sorts of test cases. This module -extends L (and therefore +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 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. +use an actual web server, and a real person to do the clicking. To create a sample test case, open the C file in your editor and enter the following: @@ -160,17 +150,19 @@ 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 + # 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'; # 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"; - + 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; my $ua2 = Test::WWW::Mechanize::Catalyst->new; @@ -225,8 +217,11 @@ editor and enter the following: $ua1->get_ok("http://localhost/books/url_create/TestTitle/2/4", "'test01' formless create"); $ua1->title_is("Book Created", "Book created title"); - $ua1->content_contains("Added book 'TestTitle' by 'Stevens'", "Check added OK"); - $ua1->content_contains("a rating of 2.", "Check rating added"); + $ua1->content_contains("Added book 'TestTitle'", "Check title added OK"); + $ua1->content_contains("by 'Stevens'", "Check author added OK"); + $ua1->content_contains("with a rating of 2.", "Check rating added"); + # Try a regular expression to combine the previous 3 checks & account for whitespace + $ua1->content_like(qr/Added book 'TestTitle'\s+by 'Stevens'\s+with a rating of 2./, "Regex check"); # Make sure the new book shows in the list $ua1->get_ok("http://localhost/books/list", "'test01' book list"); @@ -249,13 +244,13 @@ editor and enter the following: 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 -example, regex-based matching). Consult the documentation for more +variety of other methods available in +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 +by L, see L. B The test script does not test the C and @@ -274,25 +269,23 @@ or 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 the problem. +isolate and fix any problems. If you want to run the test case under the Perl interactive debugger, try a command such as: $ DBIX_CLASS_STORAGE_DBI_DEBUG=0 CATALYST_DEBUG=0 perl -d -Ilib t/live_app01.t -Note that although the tutorial uses a single custom test case for +Note that although this tutorial uses a single custom test case for simplicity, you may wish to break your tests into different files for better organization. - - =head1 SUPPORTING BOTH PRODUCTION AND TEST DATABASES 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 database specification to be overridden with an environment variable. @@ -322,15 +315,14 @@ variable defined, it will default to the same C as before. - =head1 AUTHOR Kennedy Clark, C -Please report any errors, issues or suggestions to the author. +Please report any errors, issues or suggestions to the author. The +most recent version of the Catalyst Tutorial can be found at +L. Copyright 2006, Kennedy Clark, under Creative Commons License (L). -Version: .94 -