=head1 NAME
-Catalyst::Manual::Tutorial::Testing - Catalyst Tutorial - Part 8: Testing
+Catalyst::Manual::Tutorial::Testing - Catalyst Tutorial - Chapter 8: Testing
=head1 OVERVIEW
-This is B<Part 8 of 10> for the Catalyst tutorial.
+This is B<Chapter 8 of 10> for the Catalyst tutorial.
L<Tutorial Overview|Catalyst::Manual::Tutorial>
=head1 DESCRIPTION
-You may have noticed that the Catalyst Helper scripts automatically
-create basic C<.t> test scripts under the C<t> 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<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 checkout the source code for this example from the catalyst
-subversion repository as per the instructions in
+You can check out the source code for this example from the Catalyst
+Subversion repository as per the instructions in
L<Catalyst::Manual::Tutorial::Intro|Catalyst::Manual::Tutorial::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.
+
=head1 RUNNING THE "CANNED" CATALYST TESTS
$ prove --lib lib 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'
- # in t/controller_Books.t at line 8.
+ # 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<t/01app.t> that read:
+1) Change the line in C<t/01app.t> that reads:
ok( request('/')->is_success, 'Request should succeed' );
ok( request('/login')->is_success, 'Request should succeed' );
-2) Change the C<request('/logout')-E<gt>is_success> to
-C<request('/logout')-E<gt>is_redirect> in C<t/controller_Logout.t>.
+2) Change the line in C<t/controller_Logout.t> that reads:
+
+ ok( request('/logout')->is_success, 'Request should succeed' );
+
+to:
-3) Change the C<request('/books')-E<gt>is_success> to
-C<request('/books')-E<gt>is_redirect> in C<t/controller_Books.t>.
+ ok( request('/logout')->is_redirect, 'Request should succeed' );
+
+3) Change the line in C<t/controller_Books.t> 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<t/view_TT.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
$ CATALYST_DEBUG=0 prove --lib lib t
+B<Note:> Depending on the versions of various modules you have
+installed, you might get some C<used only once> warnings -- you can
+ignore these. If you want to eliminate the warnings, you can
+edit C<Template::Base> to disable and then re-enable warnings
+are the C</usr/lib/perl5/Template/Base.pm> line in C<sub new>.
+You can locate where C<Template::Base> is located with the
+following command (it's probably in a place similar to
+C</usr/lib/perl5/Template/Base.pm>):
+
+ perldoc -l Template::Base
+
+Edit the file and modify C<sub new> to match:
+
+ ...
+ { no strict qw( refs );
+ # Disable warnings
+ no warnings;
+ $argnames = \@{"$class\::BASEARGS"} || [ ];
+ # Turn warnings back on
+ use warnings;
+ }
+ ...
+
During the C<t/02pod> and C<t/03podcoverage> tests, you might notice the
C<all skipped: set TEST_POD to enable this test> warning message. To
execute the Pod-related tests, add C<TEST_POD=1> to the C<prove>
# 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;
"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;
$_->content_contains("Book List", "Check for book list title") for $ua1, $ua2;
# Make sure the appropriate logout buttons are displayed
- $_->content_contains("/logout\">Logout</a>",
+ $_->content_contains("/logout\">User Logout</a>",
"Both users should have a 'User Logout'") for $ua1, $ua2;
$ua1->content_contains("/books/form_create\">Create</a>",
"Only 'test01' should have a create link");
$ DBIC_TRACE=0 CATALYST_DEBUG=0 prove --lib lib -v 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 (Part 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:
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
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/trunk/Catalyst-Manual/lib/Catalyst/Manual/Tutorial/>.
+L<http://dev.catalyst.perl.org/repos/Catalyst/Catalyst-Manual/5.70/trunk/lib/Catalyst/Manual/Tutorial/>.
Copyright 2006-2008, Kennedy Clark, under Creative Commons License
(L<http://creativecommons.org/licenses/by-sa/3.0/us/>).
projects / catagits/Catalyst-Manual.git / blobdiff