Mailing List Archive: Catalyst: Dev

subdomain hook for Catalyst::Test

Index | Next | Previous | View Threaded

jgottshall at capwiz

Sep 17, 2008, 3:12 PM

Post #1 of 23 (2485 views)
Permalink

subdomain hook for Catalyst::Test

Our app allows for virtual subdomains that (among other things) enable
specific behaviors in the app.

For example,
http://www.myapp.com/foo/bar
and
http://magic.myapp.com/foo/bar
both point to same app, but the latter has "magic" behaviors associated
with it.

The problem is that we're having trouble writing tests against specific
behaviors in our controller tests, particularly when we want to test
several different subdomains within the same script.

My current solution is to set an environment variable in the test script
specifing the desired subdomain. I've added hooks to the app that will
use this value if available, so that controller tests using a "local"
instance of the app instantiated with Catalyst::Test and a faked request
will Just Work. But we run into trouble when we try to run the tests
against a "remote" server by setting CATALYST_SERVER. The env var
setting embedded in the script obviously is not visible to the server
instance that's running remotely.

In order to remedy this problem, I've patched Catalyst::Test to look for
my new env var and prepend it to the CATALYST_SERVER host component. It
works great! But I'm wondering whether this patch is worthy of adding to
the core, or if there's a different way I should be approaching the
problem. Here's a diff against 5.70/trunk:

Index: lib/Catalyst/Test.pm
===================================================================
--- lib/Catalyst/Test.pm (revision 8432)
+++ lib/Catalyst/Test.pm (working copy)
@@ -148,6 +148,10 @@
my $request = Catalyst::Utils::request( shift(@_) );
my $server = URI->new( $ENV{CATALYST_SERVER} );

+ if ( $ENV{CATALYST_SUBDOMAIN} ) {
+ $server->host("$ENV{CATALYST_SUBDOMAIN}." . $server->host);
+ }
+
if ( $server->path =~ m|^(.+)?/$| ) {
my $path = $1;
$server->path("$path") if $path; # need to be quoted

If this approach makes sense, I'll add documentation to the patch, of
course. I may need a little help coming up with a working test, though.

Thoughts, anyone? Thanks,
Jason

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev[at]lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

pm at flodhest

Sep 26, 2008, 4:24 PM

Post #2 of 23 (2375 views)
Permalink

Re: subdomain hook for Catalyst::Test [In reply to]

On Thu, Sep 18, 2008 at 12:12 AM, Jason Gottshall <jgottshall[at]capwiz.com> wrote:
> Our app allows for virtual subdomains that (among other things) enable
> specific behaviors in the app.
>
> For example,
> http://www.myapp.com/foo/bar
> and
> http://magic.myapp.com/foo/bar
> both point to same app, but the latter has "magic" behaviors associated with
> it.
>
> The problem is that we're having trouble writing tests against specific
> behaviors in our controller tests, particularly when we want to test several
> different subdomains within the same script.
>
> My current solution is to set an environment variable in the test script
> specifing the desired subdomain. I've added hooks to the app that will use
> this value if available, so that controller tests using a "local" instance
> of the app instantiated with Catalyst::Test and a faked request will Just
> Work. But we run into trouble when we try to run the tests against a
> "remote" server by setting CATALYST_SERVER. The env var setting embedded in
> the script obviously is not visible to the server instance that's running
> remotely.
>
> In order to remedy this problem, I've patched Catalyst::Test to look for my
> new env var and prepend it to the CATALYST_SERVER host component. It works
> great! But I'm wondering whether this patch is worthy of adding to the core,
> or if there's a different way I should be approaching the problem. Here's a
> diff against 5.70/trunk:
>
> Index: lib/Catalyst/Test.pm
> ===================================================================
> --- lib/Catalyst/Test.pm (revision 8432)
> +++ lib/Catalyst/Test.pm (working copy)
> @@ -148,6 +148,10 @@
> my $request = Catalyst::Utils::request( shift(@_) );
> my $server = URI->new( $ENV{CATALYST_SERVER} );
>
> + if ( $ENV{CATALYST_SUBDOMAIN} ) {
> + $server->host("$ENV{CATALYST_SUBDOMAIN}." . $server->host);
> + }
> +
> if ( $server->path =~ m|^(.+)?/$| ) {
> my $path = $1;
> $server->path("$path") if $path; # need to be quoted
>
> If this approach makes sense, I'll add documentation to the patch, of
> course. I may need a little help coming up with a working test, though.
>
> Thoughts, anyone? Thanks,
> Jason
>
>
>
> _______________________________________________
> Catalyst-dev mailing list
> Catalyst-dev[at]lists.scsys.co.uk
> http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev
>

I got a possible messier suggestion:)

sub foo :Global Domain(foo.com) { .. }
sub foo :Global Domain(magic.foo.com) { .. }

The idea is (stating the obvious) adding a new attribute that match
the domain-name. Could also be regex..?

--
Best regards,
Jan Henning Thorsen

http://flodhest.net

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev[at]lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

dbix-class at trout

Sep 28, 2008, 6:17 AM

Post #3 of 23 (2368 views)
Permalink

Re: subdomain hook for Catalyst::Test [In reply to]

On Wed, Sep 17, 2008 at 06:12:48PM -0400, Jason Gottshall wrote:
> Our app allows for virtual subdomains that (among other things) enable
> specific behaviors in the app.
>
> For example,
> http://www.myapp.com/foo/bar
> and
> http://magic.myapp.com/foo/bar
> both point to same app, but the latter has "magic" behaviors associated
> with it.
>
> The problem is that we're having trouble writing tests against specific
> behaviors in our controller tests, particularly when we want to test
> several different subdomains within the same script.
>
> My current solution is to set an environment variable in the test script
> specifing the desired subdomain. I've added hooks to the app that will
> use this value if available, so that controller tests using a "local"
> instance of the app instantiated with Catalyst::Test and a faked request
> will Just Work. But we run into trouble when we try to run the tests
> against a "remote" server by setting CATALYST_SERVER. The env var
> setting embedded in the script obviously is not visible to the server
> instance that's running remotely.
>
> In order to remedy this problem, I've patched Catalyst::Test to look for
> my new env var and prepend it to the CATALYST_SERVER host component. It
> works great! But I'm wondering whether this patch is worthy of adding to
> the core, or if there's a different way I should be approaching the
> problem. Here's a diff against 5.70/trunk:

Could we not make request() take the domain or something?

It's currently single argument so adding an options hashref would be fine,
plus maybe some way to provide default values therefore in the cases where
we're doing request() from inside other code?

--
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/

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev[at]lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

jgottshall at capwiz

Sep 29, 2008, 1:32 PM

Post #4 of 23 (2360 views)
Permalink

Re: subdomain hook for Catalyst::Test [In reply to]

Jan Henning Thorsen wrote:
> On Thu, Sep 18, 2008 at 12:12 AM, Jason Gottshall <jgottshall[at]capwiz.com> wrote:
>> Our app allows for virtual subdomains that (among other things) enable
>> specific behaviors in the app.
>>
>> For example,
>> http://www.myapp.com/foo/bar
>> and
>> http://magic.myapp.com/foo/bar
>> both point to same app, but the latter has "magic" behaviors associated with
>> it.
>>
>> The problem is that we're having trouble writing tests against specific
>> behaviors in our controller tests, particularly when we want to test several
>> different subdomains within the same script.
>>
>> My current solution is to set an environment variable in the test script
>> specifing the desired subdomain. I've added hooks to the app that will use
>> this value if available, so that controller tests using a "local" instance
>> of the app instantiated with Catalyst::Test and a faked request will Just
>> Work. But we run into trouble when we try to run the tests against a
>> "remote" server by setting CATALYST_SERVER. The env var setting embedded in
>> the script obviously is not visible to the server instance that's running
>> remotely.
>>
>> In order to remedy this problem, I've patched Catalyst::Test to look for my
>> new env var and prepend it to the CATALYST_SERVER host component. It works
>> great! But I'm wondering whether this patch is worthy of adding to the core,
>> or if there's a different way I should be approaching the problem. Here's a
>> diff against 5.70/trunk:
>>
>> Index: lib/Catalyst/Test.pm
>> ===================================================================
>> --- lib/Catalyst/Test.pm (revision 8432)
>> +++ lib/Catalyst/Test.pm (working copy)
>> @@ -148,6 +148,10 @@
>> my $request = Catalyst::Utils::request( shift(@_) );
>> my $server = URI->new( $ENV{CATALYST_SERVER} );
>>
>> + if ( $ENV{CATALYST_SUBDOMAIN} ) {
>> + $server->host("$ENV{CATALYST_SUBDOMAIN}." . $server->host);
>> + }
>> +
>> if ( $server->path =~ m|^(.+)?/$| ) {
>> my $path = $1;
>> $server->path("$path") if $path; # need to be quoted
>>
>> If this approach makes sense, I'll add documentation to the patch, of
>> course. I may need a little help coming up with a working test, though.
>>
>> Thoughts, anyone? Thanks,
>> Jason
>>
>>
>>
>> _______________________________________________
>> Catalyst-dev mailing list
>> Catalyst-dev[at]lists.scsys.co.uk
>> http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev
>>
>
> I got a possible messier suggestion:)
>
> sub foo :Global Domain(foo.com) { .. }
> sub foo :Global Domain(magic.foo.com) { .. }
>
> The idea is (stating the obvious) adding a new attribute that match
> the domain-name. Could also be regex..?

I wish it were that simple! I should have been a bit clearer: we
actually use a distinct virtual subdomain for each of our customers
(2000+), and we use that value to set up wrappers and look up site
preferences, so it's not just a question of testing for explicit domain
values for specific actions.

But your comments do lead me thinking in a different direction: if I
want to write a test for the behavior of a specific site preference,
maybe I should try to force a value for that preference on the next
request, rather than trying to force the selection of a particular
virtual domain that I know (or hope) has the desired setting. Certainly
something to consider.

Thanks for sparing a few brain cells on this one...
Jason

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev[at]lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

jgottshall at capwiz

Sep 30, 2008, 8:25 AM

Post #5 of 23 (2362 views)
Permalink

Re: subdomain hook for Catalyst::Test [In reply to]

Matt S Trout wrote:
> On Wed, Sep 17, 2008 at 06:12:48PM -0400, Jason Gottshall wrote:
>> Our app allows for virtual subdomains that (among other things) enable
>> specific behaviors in the app.
>>
>> For example,
>> http://www.myapp.com/foo/bar
>> and
>> http://magic.myapp.com/foo/bar
>> both point to same app, but the latter has "magic" behaviors associated
>> with it.
>>
>> The problem is that we're having trouble writing tests against specific
>> behaviors in our controller tests, particularly when we want to test
>> several different subdomains within the same script.
>>
>> My current solution is to set an environment variable in the test script
>> specifing the desired subdomain. I've added hooks to the app that will
>> use this value if available, so that controller tests using a "local"
>> instance of the app instantiated with Catalyst::Test and a faked request
>> will Just Work. But we run into trouble when we try to run the tests
>> against a "remote" server by setting CATALYST_SERVER. The env var
>> setting embedded in the script obviously is not visible to the server
>> instance that's running remotely.
>>
>> In order to remedy this problem, I've patched Catalyst::Test to look for
>> my new env var and prepend it to the CATALYST_SERVER host component. It
>> works great! But I'm wondering whether this patch is worthy of adding to
>> the core, or if there's a different way I should be approaching the
>> problem. Here's a diff against 5.70/trunk:
>
> Could we not make request() take the domain or something?
>
> It's currently single argument so adding an options hashref would be fine,
> plus maybe some way to provide default values therefore in the cases where
> we're doing request() from inside other code?

Sounds like a nice idea. Maybe the default value could be dealt with at
import time:

use Test::More tests => 2;
use Catalyst::Test 'MyApp', { default_subdomain => 'fizzle' };

ok( request( '/foo/' )->is_success, 'foo succeeds for fizzle' );
ok( request( '/foo/', { subdomain => 'snazzle' } )->is_redirect, 'foo
redirects for snazzle');

It would be nice, though, to have a mechanism for changing the "default"
at some point, so one could run groups of tests on a single subdomain
without having to pass it explicitly with each request. Of course, one
could always just wrap a set of tests for a specific subdomain in its
own test file, but that's not quite as cool...

Matt's comments also jolted me to the realization that my original plan
for handling the subdomain for a "local" instance of the app was
probably misguided. Instead of hacking my app's code to recognize the
subdomain ENV var, I should have patched Catalyst::Test::local_request()
to mock up the subdomain in the first place. Then my code doesn't have
to have a hack solely for the test environment, and
Catalyst::Test::request() does the Right Thing regardless of whether
it's operating locally or remotely. Duh.

I'll play with this and let you know what I come up with. Thanks for the
input!

Jason

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev[at]lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

jgottshall at capwiz

Sep 30, 2008, 12:00 PM

Post #6 of 23 (2358 views)
Permalink

Re: subdomain hook for Catalyst::Test [In reply to]

Jason Gottshall wrote:
> Matt S Trout wrote:
>> Could we not make request() take the domain or something?
>>
>> It's currently single argument so adding an options hashref would be
>> fine, plus maybe some way to provide default values therefore in the
>> cases where we're doing request() from inside other code?
>
> Sounds like a nice idea. Maybe the default value could be dealt with at
> import time:
>
> use Test::More tests => 2;
> use Catalyst::Test 'MyApp', { default_subdomain => 'fizzle' };
>
> ok( request( '/foo/' )->is_success, 'foo succeeds for fizzle' );
> ok( request( '/foo/', { subdomain => 'snazzle' } )->is_redirect, 'foo
> redirects for snazzle');

Incidentally, anybody have any suggestions on how to write tests for
this behavior? I can't find any tests for Catalyst::Test itself in the
test suite. I'm thinking I could use the existing /dump/request action
in the TestApp, deserialize the request object (based on examples in the
live engine tests) and check that the request URI actually has the
subdomain injected properly. Is that sufficient? Is there an existing
test script to which I should add this, or would it make more sense to
start a new file? And what would I call it? (live_test.t, unit_test.t,
test_test_test.t?)

Jason

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev[at]lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

dbix-class at trout

Sep 30, 2008, 6:08 PM

Post #7 of 23 (2360 views)
Permalink

Re: subdomain hook for Catalyst::Test [In reply to]

On Tue, Sep 30, 2008 at 03:00:47PM -0400, Jason Gottshall wrote:
> Jason Gottshall wrote:
> >Matt S Trout wrote:
> >>Could we not make request() take the domain or something?
> >>
> >>It's currently single argument so adding an options hashref would be
> >>fine, plus maybe some way to provide default values therefore in the
> >> cases where we're doing request() from inside other code?
> >
> >Sounds like a nice idea. Maybe the default value could be dealt with at
> >import time:
> >
> > use Test::More tests => 2;
> > use Catalyst::Test 'MyApp', { default_subdomain => 'fizzle' };
> >
> > ok( request( '/foo/' )->is_success, 'foo succeeds for fizzle' );
> > ok( request( '/foo/', { subdomain => 'snazzle' } )->is_redirect, 'foo
> >redirects for snazzle');
>
> Incidentally, anybody have any suggestions on how to write tests for
> this behavior? I can't find any tests for Catalyst::Test itself in the
> test suite. I'm thinking I could use the existing /dump/request action
> in the TestApp, deserialize the request object (based on examples in the
> live engine tests) and check that the request URI actually has the
> subdomain injected properly. Is that sufficient? Is there an existing
> test script to which I should add this, or would it make more sense to
> start a new file? And what would I call it? (live_test.t, unit_test.t,
> test_test_test.t?)

marcus has done a bunch of work on C::Test in 5.80/trunk and I think that
includes some tests for it.

--
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/

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev[at]lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

dbix-class at trout

Sep 30, 2008, 6:12 PM

Post #8 of 23 (2356 views)
Permalink

Re: subdomain hook for Catalyst::Test [In reply to]

On Tue, Sep 30, 2008 at 11:25:10AM -0400, Jason Gottshall wrote:
> Matt S Trout wrote:
> >On Wed, Sep 17, 2008 at 06:12:48PM -0400, Jason Gottshall wrote:
> >>Our app allows for virtual subdomains that (among other things) enable
> >>specific behaviors in the app.
> >>
> >>For example,
> >> http://www.myapp.com/foo/bar
> >>and
> >> http://magic.myapp.com/foo/bar
> >>both point to same app, but the latter has "magic" behaviors associated
> >>with it.
> >>
> >>The problem is that we're having trouble writing tests against specific
> >>behaviors in our controller tests, particularly when we want to test
> >>several different subdomains within the same script.
> >>
> >>My current solution is to set an environment variable in the test script
> >>specifing the desired subdomain. I've added hooks to the app that will
> >>use this value if available, so that controller tests using a "local"
> >>instance of the app instantiated with Catalyst::Test and a faked request
> >>will Just Work. But we run into trouble when we try to run the tests
> >>against a "remote" server by setting CATALYST_SERVER. The env var
> >>setting embedded in the script obviously is not visible to the server
> >>instance that's running remotely.
> >>
> >>In order to remedy this problem, I've patched Catalyst::Test to look for
> >>my new env var and prepend it to the CATALYST_SERVER host component. It
> >>works great! But I'm wondering whether this patch is worthy of adding to
> >>the core, or if there's a different way I should be approaching the
> >>problem. Here's a diff against 5.70/trunk:
> >
> >Could we not make request() take the domain or something?
> >
> >It's currently single argument so adding an options hashref would be fine,
> >plus maybe some way to provide default values therefore in the cases where
> >we're doing request() from inside other code?
>
> Sounds like a nice idea. Maybe the default value could be dealt with at
> import time:
>
> use Test::More tests => 2;
> use Catalyst::Test 'MyApp', { default_subdomain => 'fizzle' };

Don't make it subdomain only, many apps serve multiple distinct hosts
(think white-labeling)

> ok( request( '/foo/' )->is_success, 'foo succeeds for fizzle' );
> ok( request( '/foo/', { subdomain => 'snazzle' } )->is_redirect, 'foo
> redirects for snazzle');
>
> It would be nice, though, to have a mechanism for changing the "default"
> at some point, so one could run groups of tests on a single subdomain
> without having to pass it explicitly with each request. Of course, one
> could always just wrap a set of tests for a specific subdomain in its
> own test file, but that's not quite as cool...

how about $Catalyst::Test::default_domain or something, and then you can do

sub with_domain {
my ($domain, $code) = @_;
local $Catalyst::Test::default_domain = $domain;
$code->();
}

with_domain 'foo.com' => sub {

ok( request ('/foo/' )->is_success, 'w00t' );

};

> Matt's comments also jolted me to the realization that my original plan
> for handling the subdomain for a "local" instance of the app was
> probably misguided. Instead of hacking my app's code to recognize the
> subdomain ENV var, I should have patched Catalyst::Test::local_request()
> to mock up the subdomain in the first place. Then my code doesn't have
> to have a hack solely for the test environment, and
> Catalyst::Test::request() does the Right Thing regardless of whether
> it's operating locally or remotely. Duh.

Spot on.

--
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/

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev[at]lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

jgottshall at capwiz

Oct 1, 2008, 2:02 PM

Post #9 of 23 (2341 views)
Permalink

Re: subdomain hook for Catalyst::Test [In reply to]

Matt S Trout wrote:
> On Tue, Sep 30, 2008 at 03:00:47PM -0400, Jason Gottshall wrote:
>> Jason Gottshall wrote:
>>> Matt S Trout wrote:
>>>> Could we not make request() take the domain or something?
>>>>
>>>> It's currently single argument so adding an options hashref would be
>>>> fine, plus maybe some way to provide default values therefore in the
>>>> cases where we're doing request() from inside other code?
>>> Sounds like a nice idea. Maybe the default value could be dealt with at
>>> import time:
>>>
>>> use Test::More tests => 2;
>>> use Catalyst::Test 'MyApp', { default_subdomain => 'fizzle' };
>>>
>>> ok( request( '/foo/' )->is_success, 'foo succeeds for fizzle' );
>>> ok( request( '/foo/', { subdomain => 'snazzle' } )->is_redirect, 'foo
>>> redirects for snazzle');
>> Incidentally, anybody have any suggestions on how to write tests for
>> this behavior? I can't find any tests for Catalyst::Test itself in the
>> test suite. I'm thinking I could use the existing /dump/request action
>> in the TestApp, deserialize the request object (based on examples in the
>> live engine tests) and check that the request URI actually has the
>> subdomain injected properly. Is that sufficient? Is there an existing
>> test script to which I should add this, or would it make more sense to
>> start a new file? And what would I call it? (live_test.t, unit_test.t,
>> test_test_test.t?)
>
> marcus has done a bunch of work on C::Test in 5.80/trunk and I think that
> includes some tests for it.

Hmm, that makes me wonder, should I be attempting to patch 5.70, 5.80,
or both?

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev[at]lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

dbix-class at trout

Oct 1, 2008, 5:37 PM

Post #10 of 23 (2343 views)
Permalink

Re: subdomain hook for Catalyst::Test [In reply to]

On Wed, Oct 01, 2008 at 05:02:03PM -0400, Jason Gottshall wrote:
> Hmm, that makes me wonder, should I be attempting to patch 5.70, 5.80,
> or both?

5.80 please.

--
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/

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev[at]lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

jgottshall at capwiz

Oct 3, 2008, 10:33 AM

Post #11 of 23 (2319 views)
Permalink

Re: subdomain hook for Catalyst::Test [In reply to]

Matt S Trout wrote:
> On Tue, Sep 30, 2008 at 11:25:10AM -0400, Jason Gottshall wrote:
>> Matt S Trout wrote:
>>> On Wed, Sep 17, 2008 at 06:12:48PM -0400, Jason Gottshall wrote:
>>>> Our app allows for virtual subdomains that (among other things) enable
>>>> specific behaviors in the app.
>>>>
>>>> For example,
>>>> http://www.myapp.com/foo/bar
>>>> and
>>>> http://magic.myapp.com/foo/bar
>>>> both point to same app, but the latter has "magic" behaviors associated
>>>> with it.
>>>>
>>>> The problem is that we're having trouble writing tests against specific
>>>> behaviors in our controller tests, particularly when we want to test
>>>> several different subdomains within the same script.
>>>>
>>>> My current solution is to set an environment variable in the test script
>>>> specifing the desired subdomain. I've added hooks to the app that will
>>>> use this value if available, so that controller tests using a "local"
>>>> instance of the app instantiated with Catalyst::Test and a faked request
>>>> will Just Work. But we run into trouble when we try to run the tests
>>>> against a "remote" server by setting CATALYST_SERVER. The env var
>>>> setting embedded in the script obviously is not visible to the server
>>>> instance that's running remotely.
>>>>
>>>> In order to remedy this problem, I've patched Catalyst::Test to look for
>>>> my new env var and prepend it to the CATALYST_SERVER host component. It
>>>> works great! But I'm wondering whether this patch is worthy of adding to
>>>> the core, or if there's a different way I should be approaching the
>>>> problem. Here's a diff against 5.70/trunk:
>>> Could we not make request() take the domain or something?
>>>
>>> It's currently single argument so adding an options hashref would be fine,
>>> plus maybe some way to provide default values therefore in the cases where
>>> we're doing request() from inside other code?
>> Sounds like a nice idea. Maybe the default value could be dealt with at
>> import time:
>>
>> use Test::More tests => 2;
>> use Catalyst::Test 'MyApp', { default_subdomain => 'fizzle' };
>
> Don't make it subdomain only, many apps serve multiple distinct hosts
> (think white-labeling)

Good point. We actually do full-blown white-labeling in addition to
virtual subdomains, which I hadn't really begun to consider yet. But it
is going to be basically the same mechanism, so it's worthing including.

Now that I think about it, what would/should happen if the test
specifies a complete white-label domain and you've got
$ENV{CATALYST_SERVER} set to run tests on a "remote" server? I guess you
would need to have a local hosts file set up to route those requests
back to the test server, or something. That's one main reason that I
still want to allow explicitly for subdomains: my local DNS already
handles virtual subdomains for the domain(s) where I run my
CATALYST_SERVER, so tests that specify a subdomain will already work
locally or remotely.

I'm happy to implement the full white-labeling piece as well, but it
seems to have some caveats...

>> ok( request( '/foo/' )->is_success, 'foo succeeds for fizzle' );
>> ok( request( '/foo/', { subdomain => 'snazzle' } )->is_redirect, 'foo
>> redirects for snazzle');
>>
>> It would be nice, though, to have a mechanism for changing the "default"
>> at some point, so one could run groups of tests on a single subdomain
>> without having to pass it explicitly with each request. Of course, one
>> could always just wrap a set of tests for a specific subdomain in its
>> own test file, but that's not quite as cool...
>
> how about $Catalyst::Test::default_domain or something, and then you can do
>
> sub with_domain {
> my ($domain, $code) = @_;
> local $Catalyst::Test::default_domain = $domain;
> $code->();
> }
>
> with_domain 'foo.com' => sub {
>
> ok( request ('/foo/' )->is_success, 'w00t' );
>
> };

Why doesn't my brain come up with lovely stuff like that?

Jason

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev[at]lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

dbix-class at trout

Oct 5, 2008, 3:20 AM

Post #12 of 23 (2300 views)
Permalink

Re: subdomain hook for Catalyst::Test [In reply to]

On Fri, Oct 03, 2008 at 01:33:00PM -0400, Jason Gottshall wrote:
> Now that I think about it, what would/should happen if the test
> specifies a complete white-label domain and you've got
> $ENV{CATALYST_SERVER} set to run tests on a "remote" server?

We should send a request to the host in that env var, with a Host: header
of whatever is specified in the test code.

> I'm happy to implement the full white-labeling piece as well, but it
> seems to have some caveats...

With the above approach, does it?

> >> ok( request( '/foo/' )->is_success, 'foo succeeds for fizzle' );
> >> ok( request( '/foo/', { subdomain => 'snazzle' } )->is_redirect, 'foo
> >>redirects for snazzle');
> >>
> >>It would be nice, though, to have a mechanism for changing the "default"
> >>at some point, so one could run groups of tests on a single subdomain
> >>without having to pass it explicitly with each request. Of course, one
> >>could always just wrap a set of tests for a specific subdomain in its
> >>own test file, but that's not quite as cool...
> >
> >how about $Catalyst::Test::default_domain or something, and then you can do
> >
> >sub with_domain {
> > my ($domain, $code) = @_;
> > local $Catalyst::Test::default_domain = $domain;
> > $code->();
> >}
> >
> >with_domain 'foo.com' => sub {
> >
> > ok( request ('/foo/' )->is_success, 'w00t' );
> >
> >};
>
> Why doesn't my brain come up with lovely stuff like that?

Insufficient lisp.

--
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/

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev[at]lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

jgottshall at capwiz

Oct 7, 2008, 6:47 AM

Post #13 of 23 (2286 views)
Permalink

Re: subdomain hook for Catalyst::Test [In reply to]

Matt S Trout wrote:
> On Fri, Oct 03, 2008 at 01:33:00PM -0400, Jason Gottshall wrote:
>> Now that I think about it, what would/should happen if the test
>> specifies a complete white-label domain and you've got
>> $ENV{CATALYST_SERVER} set to run tests on a "remote" server?
>
> We should send a request to the host in that env var, with a Host: header
> of whatever is specified in the test code.

That makes sense. I'll give that a go. Thanks.

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev[at]lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

jgottshall at capwiz

Oct 7, 2008, 7:07 AM

Post #14 of 23 (2286 views)
Permalink

Re: subdomain hook for Catalyst::Test [In reply to]

Matt S Trout wrote:
> On Tue, Sep 30, 2008 at 11:25:10AM -0400, Jason Gottshall wrote:
>> ok( request( '/foo/' )->is_success, 'foo succeeds for fizzle' );
>> ok( request( '/foo/', { subdomain => 'snazzle' } )->is_redirect, 'foo
>> redirects for snazzle');
>
> how about $Catalyst::Test::default_domain or something, and then you can do
>
> sub with_domain {
> my ($domain, $code) = @_;
> local $Catalyst::Test::default_domain = $domain;
> $code->();
> }
>
> with_domain 'foo.com' => sub {
>
> ok( request ('/foo/' )->is_success, 'w00t' );
>
> };

Here's a thought: if the (optional) alternate domain info is stored in a
package var, and therefore localizable, couldn't I then dispense with
the added argument to request() altogether? It certainly simplifies the
code; I don't have to mess with @_ anywhere. Tests can just localize the
defaults as necessary. Done.

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev[at]lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

dbix-class at trout

Oct 8, 2008, 4:18 AM

Post #15 of 23 (2278 views)
Permalink

Re: subdomain hook for Catalyst::Test [In reply to]

On Tue, Oct 07, 2008 at 10:07:32AM -0400, Jason Gottshall wrote:
> Here's a thought: if the (optional) alternate domain info is stored in a
> package var, and therefore localizable, couldn't I then dispense with
> the added argument to request() altogether? It certainly simplifies the
> code; I don't have to mess with @_ anywhere. Tests can just localize the
> defaults as necessary. Done.

You could. But isn't that gonna get kinda gross if you want to make lots
of requests each to a different domain?

--
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/

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev[at]lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

jgottshall at capwiz

Oct 8, 2008, 9:03 AM

Post #16 of 23 (2273 views)
Permalink

Re: subdomain hook for Catalyst::Test [In reply to]

Matt S Trout wrote:
> On Tue, Oct 07, 2008 at 10:07:32AM -0400, Jason Gottshall wrote:
>> Here's a thought: if the (optional) alternate domain info is stored in a
>> package var, and therefore localizable, couldn't I then dispense with
>> the added argument to request() altogether? It certainly simplifies the
>> code; I don't have to mess with @_ anywhere. Tests can just localize the
>> defaults as necessary. Done.
>
> You could. But isn't that gonna get kinda gross if you want to make lots
> of requests each to a different domain?

Yeah, I see what you mean. We're basically talking about

ok( request('/foo/', {domain => 'bar.com'})->is_success, 'bar/foo' );
ok( request('/baz/', {domain => 'qux.com'})->is_redirect, 'qux/baz' );
ok( request('/abc/', {domain => 'xyz.com'})->is_error, 'xyz/abc' );

versus

local Catalyst::Test::default_domain = 'bar.com';
ok( request('/foo/')->is_success, 'bar/foo' );
local Catalyst::Test::default_domain = 'qux.com';
ok( request('/baz/')->is_redirect, 'qux/baz' );
local Catalyst::Test::default_domain = 'xyz.com';
ok( request('/abc/')->is_error, 'xyz/abc' );

There are certainly plenty of cases where one will be simpler to use
than the other, and it's not that much more effort to make both of them
work. *Sigh* :-)

Thanks for helping me refine this idea, Matt!

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev[at]lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

apv at sedition

Oct 8, 2008, 9:40 AM

Post #17 of 23 (2271 views)
Permalink

Re: subdomain hook for Catalyst::Test [In reply to]

On Oct 8, 2008, at 9:03 AM, Jason Gottshall wrote:
> Matt S Trout wrote:
>> On Tue, Oct 07, 2008 at 10:07:32AM -0400, Jason Gottshall wrote:
>>> Here's a thought: if the (optional) alternate domain info is
>>> stored in a package var, and therefore localizable, couldn't I
>>> then dispense with the added argument to request() altogether? It
>>> certainly simplifies the code; I don't have to mess with @_
>>> anywhere. Tests can just localize the defaults as necessary. Done.
>> You could. But isn't that gonna get kinda gross if you want to
>> make lots
>> of requests each to a different domain?
>

Just throwing this out there: "domain" is probably the wrong
technical nomenclature for this however it ends up being done. URI.pm
and friends use "host" and I argue for toeing that line.

-Ashley

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev[at]lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

jgottshall at capwiz

Oct 8, 2008, 10:06 AM

Post #18 of 23 (2272 views)
Permalink

Re: subdomain hook for Catalyst::Test [In reply to]

Ashley wrote:
> On Oct 8, 2008, at 9:03 AM, Jason Gottshall wrote:
>> Matt S Trout wrote:
>>> On Tue, Oct 07, 2008 at 10:07:32AM -0400, Jason Gottshall wrote:
>>>> Here's a thought: if the (optional) alternate domain info is stored
>>>> in a package var, and therefore localizable, couldn't I then
>>>> dispense with the added argument to request() altogether? It
>>>> certainly simplifies the code; I don't have to mess with @_
>>>> anywhere. Tests can just localize the defaults as necessary. Done.
>>> You could. But isn't that gonna get kinda gross if you want to make lots
>>> of requests each to a different domain?
>>
>
> Just throwing this out there: "domain" is probably the wrong technical
> nomenclature for this however it ends up being done. URI.pm and friends
> use "host" and I argue for toeing that line.

Excellent. I've been wondering about that myself. I'll accept the idea
of going with "host" (and "default_host" as the package var) for
fully-qualified "white-label" values

Now, how do you feel about that which I've been calling "subdomain"?
That is, one or more of the left-most domain/host name elements, to be
added to whatever the standing host is at the time: 'localhost' for
local requests, or the hostname component of $ENV{CATALYST_SERVER}, or
even the newly minted "host" value noted above. I think I pulled the
term from a DNS-related RFC, but that means nothing. I'm open to
suggestions.

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev[at]lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

apv at sedition

Oct 8, 2008, 10:22 AM

Post #19 of 23 (2266 views)
Permalink

Re: subdomain hook for Catalyst::Test [In reply to]

On Oct 8, 2008, at 10:06 AM, Jason Gottshall wrote:
>> Just throwing this out there: "domain" is probably the wrong
>> technical nomenclature for this however it ends up being done.
>> URI.pm and friends use "host" and I argue for toeing that line.
>
> Excellent. I've been wondering about that myself. I'll accept the
> idea of going with "host" (and "default_host" as the package var)
> for fully-qualified "white-label" values
>
> Now, how do you feel about that which I've been calling
> "subdomain"? That is, one or more of the left-most domain/host name
> elements, to be added to whatever the standing host is at the time:
> 'localhost' for local requests, or the hostname component of $ENV
> {CATALYST_SERVER}, or even the newly minted "host" value noted
> above. I think I pulled the term from a DNS-related RFC, but that
> means nothing. I'm open to suggestions.

I think subdomains are only conceptually related to their domains (or
as a matter of dispatch convenience). Each is really either its own
host or some kind of dispatch alias like www v "" tends to be. So
there shouldn't be a reason to include anything "less than" host.
Someone feel free to club me like a baby seal if I'm talking crazy.

-Ashley

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev[at]lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

jgottshall at capwiz

Oct 8, 2008, 10:38 AM

Post #20 of 23 (2263 views)
Permalink

Re: subdomain hook for Catalyst::Test [In reply to]

Ashley wrote:
> On Oct 8, 2008, at 10:06 AM, Jason Gottshall wrote:
>> Now, how do you feel about that which I've been calling "subdomain"?
>> That is, one or more of the left-most domain/host name elements, to be
>> added to whatever the standing host is at the time: 'localhost' for
>> local requests, or the hostname component of $ENV{CATALYST_SERVER}, or
>> even the newly minted "host" value noted above. I think I pulled the
>> term from a DNS-related RFC, but that means nothing. I'm open to
>> suggestions.
>
> I think subdomains are only conceptually related to their domains (or as
> a matter of dispatch convenience). Each is really either its own host or
> some kind of dispatch alias like www v "" tends to be. So there
> shouldn't be a reason to include anything "less than" host. Someone feel
> free to club me like a baby seal if I'm talking crazy.

No clubs here, but honestly the "subdomain" case is the original problem
I was trying to solve. We use virtual subdomains to enable
customer-specific behaviors, and they could be tacked on to any number
of white-labeled base domains. My aim is to be able to modify only the
subdomain value in a test, irrespective of the rest of base domain name.

But you've got me thinking, and it does seem like my problem would be
solved by the "host" mechanism if I just accept the idea that I'll
always have to fully qualify it, even if I don't care what the rest of
the domain is...

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev[at]lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

apv at sedition

Oct 8, 2008, 11:40 AM

Post #21 of 23 (2266 views)
Permalink

Re: subdomain hook for Catalyst::Test [In reply to]

On Oct 8, 2008, at 10:38 AM, Jason Gottshall wrote:
> No clubs here, but honestly the "subdomain" case is the original
> problem I was trying to solve. We use virtual subdomains to enable
> customer-specific behaviors, and they could be tacked on to any
> number of white-labeled base domains. My aim is to be able to
> modify only the subdomain value in a test, irrespective of the rest
> of base domain name.

I only skimmed most of the earlier stuff. I suppose there could
possibly be some dynamic configuration management based on the host.
It might have to be a plugin if it sits in the top of the request cycle.

Catalyst::Plugin::ConfigPerHost ...
# load configuration variables by the c->req->uri->host

Then in config (YAML style)

Plugin::ConfigPerHost:
my.host.com: config stuff
your.host.com:
config_file: ...?

...or allow your.host.com.(conf|yml) to just work?

No idea if that's a good tack though.

> But you've got me thinking, and it does seem like my problem would
> be solved by the "host" mechanism if I just accept the idea that
> I'll always have to fully qualify it, even if I don't care what the
> rest of the domain is...

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev[at]lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

jgottshall at capwiz

Oct 9, 2008, 9:23 AM

Post #22 of 23 (2245 views)
Permalink

Re: subdomain hook for Catalyst::Test [In reply to]

Ashley wrote:
> On Oct 8, 2008, at 10:38 AM, Jason Gottshall wrote:
>> No clubs here, but honestly the "subdomain" case is the original
>> problem I was trying to solve. We use virtual subdomains to enable
>> customer-specific behaviors, and they could be tacked on to any number
>> of white-labeled base domains. My aim is to be able to modify only the
>> subdomain value in a test, irrespective of the rest of base domain name.
>
> I only skimmed most of the earlier stuff. I suppose there could possibly
> be some dynamic configuration management based on the host. It might
> have to be a plugin if it sits in the top of the request cycle.
>
> Catalyst::Plugin::ConfigPerHost ...
> # load configuration variables by the c->req->uri->host
>
> Then in config (YAML style)
>
> Plugin::ConfigPerHost:
> my.host.com: config stuff
> your.host.com:
> config_file: ...?
>
> ...or allow your.host.com.(conf|yml) to just work?
>
> No idea if that's a good tack though.

I appreciate your thoughts in this direction, but right now I'm not
trying to solve any configuration problem in the app; that's already
working just fine. The point here is how to patch Catalyst::Test to
allow me to specify a subdomain value to be used in a test request.

We've already solved the problem of specifying a fully qualified "host",
and hearing no objections I'm going to continue to use the term
"subdomain" for the mechanism that allows you to specify just a portion
of the host.

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev[at]lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

bobtfish at bobtfish

Oct 9, 2008, 4:04 PM

Post #23 of 23 (2244 views)
Permalink

Re: subdomain hook for Catalyst::Test [In reply to]

On 9 Oct 2008, at 17:23, Jason Gottshall wrote:
> We've already solved the problem of specifying a fully qualified
> "host", and hearing no objections I'm going to continue to use the
> term "subdomain" for the mechanism that allows you to specify just
> a portion of the host.

Surely this is just a case of generating the correct url?

# So a simple function
sub sub_request {
my ($sub, $path, %params) = @_;
$params{host} = $sub . '.maindomain.com';
request($path, \%params);
}

# Sub domain per request style
ok( sub_request('dom1', '/')->is_success );
ok( sub_request('dom2', '/')->is_success );

# And Matt's previous technique, but this time on the request method
directly..
sub with_domain {
my ($domain, $code) = @_;
my $orig_request = \&request;
local *request = sub { $orig_request->($_[0], { %{$_[1]}, host
=> $domain }); };
$code->();
}

# Many requests to one subdomain style
with_domain 'www.example.com' => sub {
ok( request('/')->is_success );
ok( request('/login')->is_success );
};

Cheers
t0m

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev[at]lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com