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
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
+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
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;
"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>
-(for example, regex-based matching). Consult the documentation for more
-detail.
+(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>, see L<Catalyst::Test>.
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
+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.
=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
projects / catagits/Catalyst-Manual.git / commitdiff