That’s punting a class of Catalyst errors though. Perl allows weird syntax in the “attributes” slot so you’ll only know if they’re bug-free if they go through Catalyst. I would always recommend using regular TAP style testing too. Every time you stray from standard practices you accrue unnecessary technical debt.

Example tests–

#!/usr/bin/env perl
use strict;
use warnings;
use Test::More;

use Catalyst::Test "MyApp";

# Closest to what you’re already doing.
use_ok "MyApp::Controller::Foo";

# More what I would suggest because it’s testing how the
# code is called and what it truly does.
ok request("/foo")->is_success, "GET /foo is successful";

done_testing(2);
[download]

To get a full list of the action/path endpoints you might want to test, like /foo above, you can run–

env CATALYST_DEBUG=1 ./script/myapp_server.pl
[download]

You might have trouble if you have tightly coupled models or something. It’s easy to change the configuration to mock/test DBs though. The common way, but your app might not be set up that way, is to have a myapp_test.yml/myapp_test.conf file that overrides the production/deployment models or config (in myapp.yml/myapp.conf).

I posted the above method as a *generic* means of nuking or mocking packages (thanks choroba) and, now it seems, pragmata. It's open to criticism with respect to its usage to this particular scenario, and Catalyst, of which I have no experience.

Oh, I wasn’t trying to imply anything else. It was a great solution to do what the OP wants. I just don’t think what the OP wants is the best course for this case. And he asked about possible testing approaches in reply to my other node.

Update, speling.