|
List Info
Thread: RFC: Catalyst::Test::LocalContext
|
|
| RFC: Catalyst::Test::LocalContext |

|
2007-09-17 18:32:03 |
Hi all,
I often found myself wanting to test some internal aspects
of my request
handling in Catalyst or were to lazy to check the full
returned HTML and
rather just inspect the stack.
For this purpose I expanded Catalyst::Test and threw away
its remote
functionality. So without further ado, I'd like to ask for
your comments
on this idea/module/name. POD follows.
Cheers,
Sebastian
---
NAME
Catalyst::Test::LocalContext - Test Catalyst Applications
SYNOPSIS
use Test::More tests => 5;
use Catalyst::Test::LocalContext ’TestApp’;
my $response = request(’/foo’);
isa_ok( $response, q/HTTP::Response/ )
like( get(’/foo’), qr/bar/ );
my $c = prepare(’/foo’);
ok( $c->action->name, ’foo’ )
dispatch( $c );
like( $c->response->body, qr/bar/ );
use HTTP::Request::Common;
$c = dispatch( POST( ’/foo’, [ bar => ’baz’
] ) );
is( $c->request->method, ’POST’ );
DESCRIPTION
This module tries to provide a test environment for those
situations
where Catayst::Test is simply not enough. Basically, it
allows you to
test local Catalyst applications and accesses the
dispatched context
after the request handling, or create a pristine context
object and
manipulate it at your hearts content before dispatching it
yourself.
INSTALLED METHODS
All installed methods take either an URI path, a
HTTP::Request (e.g.
one produced by HTTP::Request::Common) or a previously
prepared
context
object (with the exception of prepare() itself, for
obvious reasons).
get
Returns the content.
my $content = get(’foo/bar?test=1’);
Note that this method doesn’t follow redirects, so to
test for a
correctly redirecting page you’ll need to use a
combination of this
method and the request method below:
my $res = request(’/’); # redirects to /y
warn $res->header(’location’);
use URI;
my $uri =
URI->new($res->header(’location’));
is ( $uri->path , ’/y’);
my $content = get($uri->path);
request
Returns the "HTTP::Response" object for this
request.
my $res = request(’foo/bar?test=1’);
prepare
Returns a "Catalyst" context object (before
dispatching the actual
request). This is especially useful when you like to test
internals of
your application or your components.
my $c = prepare(’foo/bar?test=1’);
# do whatever you would do with $c in your actions
ok( $c->request->model, ’GET’ );
dispatch
Returns a "Catalyst" context object (after
executing the request) and
the "HTTP::Response" object as an array. You can
silently ignore the
response if you are not interested in it and just inspect
the context
object.
my $c = dispatch(’foo/bar?test=1’);
my ( $c, $res ) = dispatch(’foo/bar?test=2’);
INTERNAL METHODS
prepare_request
Creates and returns a new context object for a request
without
dispatching it. Also returns the HTTP::Request::AsCGI
object in list
context.
dispatch_request
Creates a new request object and runs the actual request
on it.
Returns the context object (and the response in array
context).
SEE ALSO
Catalyst, Catalyst::Test.
AUTHOR
Sebastian Willert <willert cpan.org>
Heavily based on Catalyst::Test by Sebastian Riedel
<sri cpan.org>
COPYRIGHT
This program is free software, you can redistribute it
and/or modify
it under the same terms as Perl itself.
_______________________________________________
Catalyst-dev mailing list
Catalyst-dev lists.rawmode.org
http://lists.rawmode.org/mailman/listinfo/catalyst-dev
|
|
| Re: RFC: Catalyst::Test::LocalContext |

|
2007-09-18 15:37:04 |
On Tue, Sep 18, 2007 at 01:32:03AM +0200, Sebastian Willert
wrote:
> Hi all,
>
> I often found myself wanting to test some internal
aspects of my request
> handling in Catalyst or were to lazy to check the full
returned HTML and
> rather just inspect the stack.
>
> For this purpose I expanded Catalyst::Test and threw
away its remote
> functionality. So without further ado, I'd like to ask
for your comments
> on this idea/module/name. POD follows.
The $c mocking stuff should be separate so it can be used
for unit testing.
The "test $c afterwards" stuff, maybe it should be
possible to throw a
Dumper-isation of $c over the wire or something.
More interestingly, does anybody ever actually use the
remote stuff in ::Test
directly?
--
Matt S Trout Need help with your Catalyst or
DBIx::Class project?
Technical Director http://www.shado
wcat.co.uk/catalyst/
Shadowcat Systems Ltd. Want a managed development or
deployment platform?
http://chainsawblues.vo
x.com/ http://www.shadow
cat.co.uk/servers/
_______________________________________________
Catalyst-dev mailing list
Catalyst-dev lists.rawmode.org
http://lists.rawmode.org/mailman/listinfo/catalyst-dev
|
|
| Re: RFC: Catalyst::Test::LocalContext |

|
2007-09-18 16:26:28 |
On Tue, 2007-09-18 at 21:37 +0100, Matt S Trout wrote:
> On Tue, Sep 18, 2007 at 01:32:03AM +0200, Sebastian
Willert wrote:
> > Hi all,
> >
> > I often found myself wanting to test some internal
aspects of my request
> > handling in Catalyst or were to lazy to check the
full returned HTML and
> > rather just inspect the stack.
> >
> > For this purpose I expanded Catalyst::Test and
threw away its remote
> > functionality. So without further ado, I'd like to
ask for your comments
> > on this idea/module/name. POD follows.
>
> The $c mocking stuff should be separate so it can be
used for unit testing.
I don't really mock that much, basically I just split
Catalyst::Test::local_request after the prepare and do some
namespace
trickery to keep the HTTP::Request::AsCGI stuff accessible.
Actually
I've experimented with mocking $c, but this turned out
unyielding for a
general purpose test helper. There are to many plugins
around that would
all need special preparation that your far better of just
sticking to
the established context setup and fake the request instead
of the
context.
> The "test $c afterwards" stuff, maybe it
should be possible to throw a
> Dumper-isation of $c over the wire or something.
To support both local and remote requests within this
module? I doubt
so. Just for starters you can't even be sure that the dump
would be
re-parsed correctly because of different module versions,
unavailability
of certain modules, stuff like that, and it can't really be
done without
modifying the app to be tested. Additionally I have the gut
feeling that
access to the context before it is dispatched is nearly as
useful as
getting it after the fact. And this would be impossible to
do over the
wire.
> More interestingly, does anybody ever actually use the
remote stuff in ::Test
> directly?
Just a few days ago while patching up some test cases in
trunk ;) apart
from this, I've never done so before and I doubt I ever
will.
Cheers,
Sebastian
_______________________________________________
Catalyst-dev mailing list
Catalyst-dev lists.rawmode.org
http://lists.rawmode.org/mailman/listinfo/catalyst-dev
|
|
| Re: RFC: Catalyst::Test::LocalContext |

|
2007-09-19 11:15:57 |
On Tue, Sep 18, 2007 at 11:26:28PM +0200, Sebastian Willert
wrote:
> On Tue, 2007-09-18 at 21:37 +0100, Matt S Trout wrote:
> > On Tue, Sep 18, 2007 at 01:32:03AM +0200,
Sebastian Willert wrote:
> > > Hi all,
> > >
> > > I often found myself wanting to test some
internal aspects of my request
> > > handling in Catalyst or were to lazy to check
the full returned HTML and
> > > rather just inspect the stack.
> > >
> > > For this purpose I expanded Catalyst::Test
and threw away its remote
> > > functionality. So without further ado, I'd
like to ask for your comments
> > > on this idea/module/name. POD follows.
> >
> > The $c mocking stuff should be separate so it can
be used for unit testing.
>
> I don't really mock that much, basically I just split
> Catalyst::Test::local_request after the prepare and do
some namespace
> trickery to keep the HTTP::Request::AsCGI stuff
accessible. Actually
> I've experimented with mocking $c, but this turned out
unyielding for a
> general purpose test helper. There are to many plugins
around that would
> all need special preparation that your far better of
just sticking to
> the established context setup and fake the request
instead of the
> context.
I said for unit testing.
If you need to make plugins happy then you aren't unit
testing.
> > The "test $c afterwards" stuff, maybe it
should be possible to throw a
> > Dumper-isation of $c over the wire or something.
>
> To support both local and remote requests within this
module? I doubt
> so. Just for starters you can't even be sure that the
dump would be
> re-parsed correctly because of different module
versions, unavailability
> of certain modules, stuff like that, and it can't
really be done without
> modifying the app to be tested. Additionally I have the
gut feeling that
> access to the context before it is dispatched is nearly
as useful as
> getting it after the fact. And this would be impossible
to do over the
> wire.
For simple stuff it should be very possible.
Anything else should either be a unit test (so mocked $c and
none of this crap
anyway) for specific controller actions etc, or an
integration test at which
point you need to be using the mech stuff anyway.
The only case in between I can think of is trivially covered
with a testing
view that returns a Dumper of $c->stash or similar.
> > More interestingly, does anybody ever actually use
the remote stuff in ::Test
> > directly?
>
> Just a few days ago while patching up some test cases
in trunk ;) apart
> from this, I've never done so before and I doubt I ever
will.
So maybe what we really need is a way to declare "these
only work locally"
test blocks that auto-skip when doing the remote bits - then
your functionality
can be merged into Catalyst::Test without a problem.
--
Matt S Trout Need help with your Catalyst or
DBIx::Class project?
Technical Director http://www.shado
wcat.co.uk/catalyst/
Shadowcat Systems Ltd. Want a managed development or
deployment platform?
http://chainsawblues.vo
x.com/ http://www.shadow
cat.co.uk/servers/
_______________________________________________
Catalyst-dev mailing list
Catalyst-dev lists.rawmode.org
http://lists.rawmode.org/mailman/listinfo/catalyst-dev
|
|
[1-4]
|
|