=head1 DESCRIPTION
-You may have noticed that the Catalyst Helper scripts automatically
-create basic C<.t> test scripts under the C<t> 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<Catalyst::Manual::Tutorial::01_Intro|Catalyst::Manual::Tutorial::01_Intro>.
+You may have noticed that the Catalyst Helper scripts automatically
+create basic C<.t> test scripts under the C<t> 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.
+
+Source code for the tutorial in included in the F</home/catalyst/Final>
+directory of the Tutorial Virtual machine (one subdirectory per
+chapter). There are also instructions for downloading the code in
+L<Catalyst::Manual::Tutorial::01_Intro>.
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.
+your Perl applications and modules, you might want to read 'Perl
+Testing: A Developer's Notebook' by Ian Langworth and chromatic.
=head1 RUNNING THE "CANNED" CATALYST TESTS
There are a variety of ways to run Catalyst and Perl tests (for example,
-C<perl Makefile.PL> and C<make test>), but one of the easiest is with the
-C<prove> command. For example, to run all of the tests in the C<t>
+C<perl Makefile.PL> and C<make test>), but one of the easiest is with
+the C<prove> command. For example, to run all of the tests in the C<t>
directory, enter:
$ prove -wl t
-There will be a lot of output because we have the C<-Debug> flag
-enabled in C<lib/MyApp.pm> (see the C<CATALYST_DEBUG=0> tip below for
-a quick and easy way to reduce the clutter). Look for lines like this
-for errors:
+There will be a lot of output because we have the C<-Debug> flag enabled
+in C<lib/MyApp.pm> (see the C<CATALYST_DEBUG=0> 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
+The redirection used by the Authentication plugins will cause several
failures in the default tests. You can fix this by making the following
changes:
ok( request('/books')->is_redirect, 'Request should succeed' );
-4) Add the following statement to the top of C<t/view_TT.t>:
+4) Add the following statement to the top of C<t/view_HTML.t>:
use MyApp;
-As you can see in the C<prove> command line above, the C<--lib> option
-is used to set the location of the Catalyst C<lib> directory. With this
-command, you will get all of the usual development server debug output,
-something most people prefer to disable while running tests cases.
-Although you can edit the C<lib/MyApp.pm> to comment out the C<-Debug>
-plugin, it's generally easier to simply set the C<CATALYST_DEBUG=0>
-environment variable. For example:
+As you can see in the C<prove> command line above, the C<-l> option (or
+C<--lib> if you prefer) is used to set the location of the Catalyst
+C<lib> directory. With this command, you will get all of the usual
+development server debug output, something most people prefer to disable
+while running tests cases. Although you can edit the C<lib/MyApp.pm> to
+comment out the C<-Debug> plugin, it's generally easier to simply set
+the C<CATALYST_DEBUG=0> environment variable. For example:
$ CATALYST_DEBUG=0 prove -wl t
Another useful option is the C<verbose> (C<-v>) option to C<prove>. It
prints the name of each test case as it is being run:
- $ CATALYST_DEBUG=0 TEST_POD=1 prove -vwl t
+ $ CATALYST_DEBUG=0 prove -vwl t
=head1 RUNNING A SINGLE TEST
$ CATALYST_DEBUG=0 prove -wl t/01app.t
-Also note that you can also run tests directly from Perl without C<prove>.
-For example:
+Also note that you can also run tests directly from Perl without
+C<prove>. For example:
$ CATALYST_DEBUG=0 perl -w -Ilib t/01app.t
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<Test::WWW::Mechanize::Catalyst|Test::WWW::Mechanize::Catalyst> module
-is very popular for writing these sorts of test cases. This module
-extends L<Test::WWW::Mechanize|Test::WWW::Mechanize> (and therefore
-L<WWW::Mechanize|WWW::Mechanize>) to allow you to automate the action of
+your own tests to exercise the various parts of your application. The
+L<Test::WWW::Mechanize::Catalyst> module is very popular for writing
+these sorts of test cases. This module extends L<Test::WWW::Mechanize>
+(and therefore L<WWW::Mechanize>) 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.
To create a sample test case, open the C<t/live_app01.t> file in your
editor and enter the following:
- #!/usr/bin/perl
+ #!/usr/bin/env perl
use strict;
use warnings;
# use 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;
my $ua2 = Test::WWW::Mechanize::Catalyst->new;
"Check we are NOT logged in") for $ua1, $ua2;
# Log back in
- $ua1->get_ok("http://localhost/login?username=test01&password=mypass", "Login 'test01'");
- $ua2->get_ok("http://localhost/login?username=test02&password=mypass", "Login 'test02'");
+ $ua1->get_ok("http://localhost/login?username=test01&password=mypass",
+ "Login 'test01'");
+ $ua2->get_ok("http://localhost/login?username=test02&password=mypass",
+ "Login 'test02'");
# Should be at the Book List page... do some checks to confirm
$_->title_is("Book List", "Check for book list title") for $ua1, $ua2;
$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");
+ $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");
$ua1->get_ok($delLinks[$#delLinks]->url, 'Delete last book');
# Check that delete worked
$ua1->content_contains("Book List", "Book List page test");
- $ua1->content_contains("Book deleted", "Book was deleted");
+ $ua1->content_like(qr/Deleted book \d+/, "Deleted book #");
# User 'test02' should not be able to add a book
$ua2->get_ok("http://localhost/books/url_create/TestTitle2/2/5", "'test02' add");
The C<live_app.t> 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<Test::WWW::Mechanize::Catalyst|Test::WWW::Mechanize::Catalyst> (for
-example, regex-based matching). Consult the documentation for more
-detail.
+variety of other methods available in L<Test::WWW::Mechanize::Catalyst>
+(for example, regex-based matching). Consult
+L<Test::WWW::Mechanize::Catalyst>, L<Test::WWW::Mechanize>,
+L<WWW::Mechanize>, and L<Test::More> for more detail.
B<TIP>: For I<unit tests> vs. the "full application tests" approach used
-by L<Test::WWW::Mechanize::Catalyst|Test::WWW::Mechanize::Catalyst>, see
-L<Catalyst::Test|Catalyst::Test>.
+by L<Test::WWW::Mechanize::Catalyst>, see L<Catalyst::Test>.
B<Note:> The test script does not test the C<form_create> and
C<form_create_do> actions. That is left as an exercise for the reader
$ DBIC_TRACE=0 CATALYST_DEBUG=0 prove -vwl t/live_app01.t
-Experiment with the C<DBIC_TRACE>, C<CATALYST_DEBUG> 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.
+Experiment with the C<DBIC_TRACE>, C<CATALYST_DEBUG> 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:
Unfortunately, this only shows us the first 50 characters of the HTML
returned by the request -- not enough to determine where the problem
-lies. A simple technique that can be used in such situations is to
-temporarily insert a line similar to the following right after the
+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:
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.
+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
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<Test::WWW::Mechanize::Catalyst|Test::WWW::Mechanize::Catalyst> is that
-it runs your full application; however, this can complicate things when
-you want to support multiple databases.
+L<Test::WWW::Mechanize::Catalyst> is that it runs your full application;
+however, this can complicate things when 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<lib/MyApp/Model/DB.pm> in your editor and
-change the C<__PACKAGE__-E<gt>config(...> declaration to resemble:
+One solution is to allow the database specification to be overridden
+with an environment variable. For example, open
+C<lib/MyApp/Model/DB.pm> in your editor and change the
+C<__PACKAGE__-E<gt>config(...> declaration to resemble:
my $dsn = $ENV{MYAPP_DSN} ||= 'dbi:SQLite:myapp.db';
__PACKAGE__->config(
variable defined, it will default to the same C<dbi:SQLite:myapp.db> as
before.
+
=head2 DATABASE CONFIG SWITCHING USING MULTIPLE CONFIG FILES
-By utilizing L<Catalyst::Plugin::ConfigLoader>s functionality for loading
-multiple config files based on environment variables you can override your
-default (production) database connection settings.
+L<Catalyst::Plugin::ConfigLoader> has functionality to load loading
+multiple config files based on environment variablesi, allowing you to
+override your default (production) database connection settings during
+development (or vice versa).
-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.
+Setting C<$ENV{ MYAPP_CONFIG_LOCAL_SUFFIX }> to 'testing' in your test
+script results in loading of an additional config file named
+C<myapp_testing.conf> after C<myapp.conf> which will override any
+parameters in C<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.
+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:
+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:
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' );
+You can jump to the next chapter of the tutorial here:
+L<Advanced CRUD|Catalyst::Manual::Tutorial::09_AdvancedCRUD>
+
+
=head1 AUTHOR
Kennedy Clark, C<hkclark@gmail.com>
-Please report any errors, issues or suggestions to the author. The
-most recent version of the Catalyst Tutorial can be found at
-L<http://dev.catalyst.perl.org/repos/Catalyst/Catalyst-Manual/5.80/trunk/lib/Catalyst/Manual/Tutorial/>.
+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
+L<https://rt.cpan.org/Public/Dist/Display.html?Name=Catalyst-Manual>.
-Copyright 2006-2010, Kennedy Clark, under Creative Commons License
+Copyright 2006-2011, Kennedy Clark, under the
+Creative Commons Attribution Share-Alike License Version 3.0
(L<http://creativecommons.org/licenses/by-sa/3.0/us/>).
-
projects / catagits/Catalyst-Manual.git / blobdiff