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
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:
# 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
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
"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. 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
projects / catagits/Catalyst-Manual.git / blobdiff