[Catalyst-dev] RFC: Catalyst::Test::LocalContext

[Matt S Trout]

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.shadowcat.co.uk/catalyst/
 Shadowcat Systems Ltd.  Want a managed development or deployment platform?
http://chainsawblues.vox.com/            http://www.shadowcat.co.uk/servers/