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>.
+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:
C<prove> command. For example, to run all of the tests in the C<t>
directory, enter:
- $ prove --lib lib t
+ $ 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
plugin, it's generally easier to simply set the C<CATALYST_DEBUG=0>
environment variable. For example:
- $ 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;
- }
- ...
+ $ CATALYST_DEBUG=0 prove -wl 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
execute the Pod-related tests, add C<TEST_POD=1> to the C<prove>
command:
- $ CATALYST_DEBUG=0 TEST_POD=1 prove --lib lib t
+ $ CATALYST_DEBUG=0 TEST_POD=1 prove -wl t
If you omitted the Pod comments from any of the methods that were
inserted, you might have to go back and fix them to get these tests to
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 --lib lib -v t
+ $ CATALYST_DEBUG=0 TEST_POD=1 prove -vwl t
=head1 RUNNING A SINGLE TEST
You can also run a single script by appending its name to the C<prove>
command. For example:
- $ CATALYST_DEBUG=0 prove --lib lib t/01app.t
+ $ CATALYST_DEBUG=0 prove -wl t/01app.t
Also note that you can also run tests directly from Perl without C<prove>.
For example:
- $ CATALYST_DEBUG=0 perl -Ilib t/01app.t
+ $ CATALYST_DEBUG=0 perl -w -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
+L<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
+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.
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
-
- use Test::More 'no_plan';
+ use Test::More;
# 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";
+ 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;
# User 'test02' should not be able to add a book
$ua2->get_ok("http://localhost/books/url_create/TestTitle2/2/5", "'test02' add");
$ua2->content_contains("Unauthorized!", "Check 'test02' cannot add");
+
+ done_testing;
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
+L<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
-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
To run the new test script, use a command such as:
- $ CATALYST_DEBUG=0 prove --lib lib -v t/live_app01.t
+ $ CATALYST_DEBUG=0 prove -vwl t/live_app01.t
or
- $ DBIC_TRACE=0 CATALYST_DEBUG=0 prove --lib lib -v t/live_app01.t
+ $ 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
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
+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:
my $dsn = $ENV{MYAPP_DSN} ||= 'dbi:SQLite:myapp.db';
__PACKAGE__->config(
schema_class => 'MyApp::Schema',
- connect_info => [
- $dsn,
- ],
+
+ connect_info => {
+ dsn => $dsn,
+ user => '',
+ password => '',
+ on_connect_do => q{PRAGMA foreign_keys = ON},
+ }
);
Then, when you run your test case, you can use commands such as:
$ cp myapp.db myappTEST.db
- $ CATALYST_DEBUG=0 MYAPP_DSN="dbi:SQLite:myappTEST.db" prove --lib lib -v t/live_app01.t
+ $ CATALYST_DEBUG=0 MYAPP_DSN="dbi:SQLite:myappTEST.db" prove -vwl t/live_app01.t
This will modify the DSN only while the test case is running. If you
launch your normal application without the C<MYAPP_DSN> environment
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.
+
+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.
+
+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:
+
+myapp_testing.conf:
+
+ <Model::MyDB>
+ <connect_info>
+ dsn dbi:SQLite:myapp.db
+ </connect_info>
+ </Model::MyDB>
+
+
+t/controller_Foo.t:
+
+ 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' );
+
=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
+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
+<https://rt.cpan.org/Public/Dist/Display.html?Name=Catalyst-Manual>.
+
+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/>.
-Copyright 2006-2008, Kennedy Clark, under Creative Commons License
+Copyright 2006-2010, Kennedy Clark, under the
+Creative Commons Attribution Share-Alike License Version 3.0
(L<http://creativecommons.org/licenses/by-sa/3.0/us/>).
-