Cross-domain testing
Boris Zbarsky
Ideally we could do this without having to actually hit the network; is it
possible with the test HTTP server we have?
The basic requirements are that we need multiple domains, some sharing
subdomains, so we can test document.domain setting, cross-site access to various
properties, and so forth.
-Boris
Dave Liebreich
> We need some way of running cross-domain tests (security, web compat,
> etc). Ideally we could do this without having to actually hit the
> network; is it possible with the test HTTP server we have?
Which test HTTP server? The necko one? I think it does. Check bug
342877 for the latest info.
>
> The basic requirements are that we need multiple domains, some sharing
> subdomains, so we can test document.domain setting, cross-site access to
> various properties, and so forth.
I'm probably restating the obvious, or at least preaching to the choir,
but . . .
It's not going to be easy to set up a test environment on every dev's
desktop. One long-term solution is to change the code to make it more
testable at the code level, so we don't have to instantiate a full
browser app and run it in a full end-to-end server environment to run tests.
But we should still write tests and make the full environment setup as
easy as reasonable so that developers can run these tests.
--
Dave Liebreich
Test Architect, Mozilla Corporation
Boris Zbarsky
> Which test HTTP server? The necko one?
Yeah.
> It's not going to be easy to set up a test environment on every dev's
> desktop.
That's somewhat unfortunate... :(
> But we should still write tests and make the full environment setup as
> easy as reasonable so that developers can run these tests.
Right. I buy that. ;)
-Boris
Jeff Walden
> We need some way of running cross-domain tests (security, web compat,
> etc). Ideally we could do this without having to actually hit the
> network; is it possible with the test HTTP server we have?
The server in bug 342877 can be run on multiple local ports, so you could do <http://localhost:8080/>, <http://localhost:8081/>, <http://localhost:8082/>, etc. as much as you wanted to do it (tho you'd probably only need two in most cases). (The server's sort of stalled for now because biesi hasn't found time to review the 140K patch [tho in its defense a well-documented one, and probably >70K of it is tests, docs, or tweaks to existing netwerk tests to use it] for code which provides non-essential testing-only functionality; want to pick up that review? ;-) )
> The basic requirements are that we need multiple domains, some sharing
> subdomains, so we can test document.domain setting, cross-site access to
> various properties, and so forth.
I'm not aware how one sets up localhost subdomains and don't know if it's possible without some particularly specialized component not already in Necko. Maybe it can be hacked together with a non-proxying proxy which makes, say, http://mozilla.example.org/ be a synonym for <http://localhost:8080/>, but since that's a spur-of-the-moment idea I haven't investigated it at all, even to determine feasibility.
Jeff
--
Rediscover the Web!
http://snurl.com/get_firefox
Reclaim Your Inbox!
http://snurl.com/get_thunderbird
Frank Wein
> Boris Zbarsky wrote:
[...]
>> The basic requirements are that we need multiple domains, some sharing
>> subdomains, so we can test document.domain setting, cross-site access
>> to various properties, and so forth.
>
> I'm not aware how one sets up localhost subdomains and don't know if
> it's possible without some particularly specialized component not
> already in Necko. Maybe it can be hacked together with a non-proxying
> proxy which makes, say, http://mozilla.example.org/ be a synonym for
> <http://localhost:8080/>, but since that's a spur-of-the-moment idea I
> haven't investigated it at all, even to determine feasibility.
>
> Jeff
With the SOCKS protocol you can use the SOCKS proxy to resolve the
domains (instead of asking the OS). So maybe the server should implement
the SOCKS protocol for doing this... ;).
Frank