List Info

Thread: RFC: Catalyst::Test::LocalContext




RFC: Catalyst::Test::LocalContext
user name
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 <willertcpan.org>

  Heavily based on Catalyst::Test by Sebastian Riedel
<sricpan.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-devlists.rawmode.org
http://lists.rawmode.org/mailman/listinfo/catalyst-dev


Re: RFC: Catalyst::Test::LocalContext
user name
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-devlists.rawmode.org
http://lists.rawmode.org/mailman/listinfo/catalyst-dev


Re: RFC: Catalyst::Test::LocalContext
user name
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-devlists.rawmode.org
http://lists.rawmode.org/mailman/listinfo/catalyst-dev


Re: RFC: Catalyst::Test::LocalContext
user name
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-devlists.rawmode.org
http://lists.rawmode.org/mailman/listinfo/catalyst-dev


[1-4]

about | contact  Other archives ( Real Estate discussion Medical topics )