Catalyst::Manual::Tutorial::Testing - Catalyst Tutorial - Part 7: Testing
-
-
=head1 OVERVIEW
This is B<Part 7 of 9> for the Catalyst tutorial.
=item 9
-L<Appendicies|Catalyst::Manual::Tutorial::Appendicies>
+L<Appendices|Catalyst::Manual::Tutorial::Appendices>
=back
-
-
=head1 DESCRIPTION
-
You may have noticed that the Catalyst Helper scripts automatically
-create 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.
+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.
B<TIP>: 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 checkout http://dev.catalyst.perl.org/repos/Catalyst/trunk/examples/Tutorial@4614 .
=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<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:
plugin, it's generally easier to simply set the C<CATALYST_DEBUG=0>
environment variable. For example:
- CATALYST_DEBUG=0 prove --lib lib t
+ $ CATALYST_DEBUG=0 prove --lib lib t
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
$ 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<prove>
$ 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<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<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
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<t/live_app01.t> file in your
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;
$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("Added book 'TestTitle'", "Check title added OK");
+ $ua1->content_contains("by 'Stevens'", "Check author added OK");
$ua1->content_contains("a rating of 2.", "Check rating added");
# Make sure the new book shows in the list
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
+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.
B<TIP>: For I<unit tests> vs. the "full application tests" approach used
-by L<Test::WWW::Mechanize::Catalyst|Test::WWW::Mechanize::Catalyst>, see
+by L<Test::WWW::Mechanize::Catalyst|Test::WWW::Mechanize::Catalyst>, see
L<Catalyst::Test|Catalyst::Test>.
B<Note:> The test script does not test the C<form_create> and
Experiment with the C<DBIX_CLASS_STORAGE_DBI_DEBUG>, C<CATALYST_DEBUG>
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<Test::WWW::Mechanize::Catalyst|Test::WWW::Mechanize::Catalyst> is that
+L<Test::WWW::Mechanize::Catalyst> 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.
before.
-
=head1 AUTHOR
Kennedy Clark, C<hkclark@gmail.com>
-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 Catlayst Tutorial can be found at
+L<http://dev.catalyst.perl.org/repos/Catalyst/trunk/Catalyst-Runtime/lib/Catalyst/Manual/Tutorial/>.
Copyright 2006, Kennedy Clark, under Creative Commons License
(L<http://creativecommons.org/licenses/by-nc-sa/2.5/>).
-Version: .94
-
projects / catagits/Catalyst-Runtime.git / blobdiff