investigating browserscope for URI testing
Chris Weber
to create for RFC3986 and 3987. Is there someone I can talk with before
I dive too far into trying to get this setup and working?
thank you,
Chris Weber
Chris Weber
question or to more recent ones from other folks.
elsigh
Hey Chris,
If you can automate a test webpage which exercises a browser and
produces a pass/fail result then Browserscope can certainly help you.
Do you think this sort of test might belong in one of the existing,
hosted test suites? Or do you want to make and host your own test?
Happy to help,
Lindsey
elsigh
Thanks for the fast reply! I have two requirements:
1) I want to capture the DOM parsing of a URI in an /a/@href. Easy to
do with some javascript to pull the DOM properties, then I want to
package up the data and send it to a Web page that can collect the
data, parsing the referrer header to get the test ID, and parsing/
collecting the User-Agent string.
2) I want to capture the HTTP request that gets generated from an /img/
@src. So the URI reference would need to point back to the server
hosting the test case. The server would need to capture requests to
arbitrary paths e.g. might be /foo1/?x=y for one test case and /foo2/
foo3/ for another.
I basically want to build a conformance testing suite for URIs/IRIs.
I don't have the Python, Django, or AppEngine experience to feel
comfortable doing this with Browserscope, and was honestly hoping that
someone from your team might be interested to carry some the weight
building out those parts while I build out and describe the test
cases. A collaborative effort.
URI/IRI testing seems like it could be a valuable addition to your
test framework :)
Thanks,
Chris Weber
elsigh
On Aug 10, 2:40 pm, elsigh <els...@gmail.com> wrote:
> And Chris replied:
> Thanks for the fast reply! I have two requirements:
>
> 1) I want to capture the DOM parsing of a URI in an /a/@href. Easy to
> do with some javascript to pull the DOM properties, then I want to
> package up the data and send it to a Web page that can collect the
> data, parsing the referrer header to get the test ID, and parsing/
> collecting the User-Agent string.
object which represents your results, a Browserscope user test will
handle the rest for you.
>
> 2) I want to capture the HTTP request that gets generated from an /img/
> @src. So the URI reference would need to point back to the server
> hosting the test case. The server would need to capture requests to
> arbitrary paths e.g. might be /foo1/?x=y for one test case and /foo2/
> foo3/ for another.
>
> I basically want to build a conformance testing suite for URIs/IRIs.
> I don't have the Python, Django, or AppEngine experience to feel
> comfortable doing this with Browserscope, and was honestly hoping that
> someone from your team might be interested to carry some the weight
> building out those parts while I build out and describe the test
> cases. A collaborative effort.
enough to build it.
Also, in general we want to have people who need/want the tests write
them so that they are correct and maintained going forward.
Python/Django/App Engine should be pretty easy to grok if you look for
instance at the Network test examples.
http://code.google.com/p/browserscope/source/browse/trunk/categories/network/handlers.py
See http://code.google.com/p/browserscope/source/browse/trunk/categories/network/templates/tests/link-prefetch.html
for one particular test example.
Check out: http://code.google.com/p/browserscope/wiki/Contributing
I hope that's helpful. If you get stuck anywhere along the way I'm
happy to help, but I don't think I could commit to writing these tests
at the moment.
Chris Weber
> I think if you can do the DOM parsing bit in /a/@href and construct an
> object which represents your results, a Browserscope user test will
> handle the rest for you.
>
I looked into this and the result object didn't seem descriptive enough
- e.g. it only accepted an name/integer pair.
> Hm, can you use cuzillion? What will you do with these requests?
>
Dunno, will have to check. I won't always have an 'expected' result to
reference.
> I'm honestly not quite sure I understand what/why you're testing well
> enough to build it.
> Also, in general we want to have people who need/want the tests write
> them so that they are correct and maintained going forward.
I have the test cases written and plan to maintain them. This is
testing against URI and IRI parsing and generation in accordance with
RFC3986 and RFC3987bis.
>
> Python/Django/App Engine should be pretty easy to grok if you look for
> instance at the Network test examples.
> http://code.google.com/p/browserscope/source/browse/trunk/categories/network/handlers.py
> See http://code.google.com/p/browserscope/source/browse/trunk/categories/network/templates/tests/link-prefetch.html
> for one particular test example.
From the server-side I basically need 2 things. A single Web page that
collects the results of DOM parsing - e.g. a very light RESTful Web
service. And the other code to collect HTTP requests at a lower-level
- e.g. an arbitrary path, sort of like a default HTTP handler. I have
this all working now in C#/ASP.NET but I don't know what the equivalent
is in your framework. It's not a lot of code, just a couple hundred
lines, but I'm not familiar with your framework's capabilities.
>
> Check out: http://code.google.com/p/browserscope/wiki/Contributing
>
> I hope that's helpful. If you get stuck anywhere along the way I'm
> happy to help, but I don't think I could commit to writing these tests
> at the moment.
>
I don't need help writing the tests, I have plenty of them ready to go.
I just need the 2 components mentioned above to collect their results.
However I don't know if it's possible with your framework to implement
the equivalent of a Microsoft IIS HTTP handler which is necessary
because many of the tests will resolve HTTP requests to arbitrary path
locations. This is for URI parsing so we want to test things like
http://www.example.com/foobar/ and http://www.example.com/foo;bar/. In
this one small example Firefox sees the path as /foo whereas other
browsers see the path as /foo;bar.
elsigh
On Aug 10, 3:07 pm, Chris Weber <ch...@lookout.net> wrote:
> On 8/10/2011 5:46 PM, elsigh wrote:
>
> > I think if you can do the DOM parsing bit in /a/@href and construct an
> > object which represents your results, a Browserscope user test will
> > handle the rest for you.
>
> I looked into this and the result object didn't seem descriptive enough
> - e.g. it only accepted an name/integer pair.
{
'test_one': 1,
'test_two: 2
}
Where 1/0 is pass/fail.
Of course you can store integers there up to a much higher number, but
for all our spec tests, the results are booleans like this.
> > Hm, can you use cuzillion? What will you do with these requests?
>
> Dunno, will have to check. I won't always have an 'expected' result to
> reference.
>
> > I'm honestly not quite sure I understand what/why you're testing well
> > enough to build it.
> > Also, in general we want to have people who need/want the tests write
> > them so that they are correct and maintained going forward.
>
> I have the test cases written and plan to maintain them. This is
> testing against URI and IRI parsing and generation in accordance with
> RFC3986 and RFC3987bis.
>
>
>
> > Python/Django/App Engine should be pretty easy to grok if you look for
> > instance at the Network test examples.
> > Seehttp://code.google.com/p/browserscope/source/browse/trunk/categories/...
>
> From the server-side I basically need 2 things. A single Web page that
> collects the results of DOM parsing - e.g. a very light RESTful Web
> service. And the other code to collect HTTP requests at a lower-level
> - e.g. an arbitrary path, sort of like a default HTTP handler. I have
> this all working now in C#/ASP.NET but I don't know what the equivalent
> is in your framework. It's not a lot of code, just a couple hundred
> lines, but I'm not familiar with your framework's capabilities.
>
HTTPRequestHandler (django's version of what you're talking about).
Maybe you could send me an URL with an example and think about the
format for the results as I outlined above.
This might be easy enough for me to help you get started on and then
you could just rock the rest.
>
>
> > Check out:http://code.google.com/p/browserscope/wiki/Contributing
>
> > I hope that's helpful. If you get stuck anywhere along the way I'm
> > happy to help, but I don't think I could commit to writing these tests
> > at the moment.
>
> I don't need help writing the tests, I have plenty of them ready to go.
> I just need the 2 components mentioned above to collect their results.
> However I don't know if it's possible with your framework to implement
> the equivalent of a Microsoft IIS HTTP handler which is necessary
> because many of the tests will resolve HTTP requests to arbitrary path
Chris Weber
>
> What do you need? The premise of Browserscope is that you can store:
>
> {
> 'test_one': 1,
> 'test_two: 2
> }
>
> Where 1/0 is pass/fail.
>
> Of course you can store integers there up to a much higher number, but
> for all our spec tests, the results are booleans like this.
I could make that work for some of the cases where there's a clear idea
of the expected result. But the goal with this was also to document
browser behavior where we don't really have a good reference for what's
expected. So instead of capturing a pass/fail result, I want to capture
how a given URI was parsed, resolved against a base, and generated - in
those cases the result would be an arbitrary string.
>
> You could definitely map handlers in the urls.py file to a
> HTTPRequestHandler (django's version of what you're talking about).
>
> Maybe you could send me an URL with an example and think about the
> format for the results as I outlined above.
> This might be easy enough for me to help you get started on and then
> you could just rock the rest.
>
That would rock. As an example - the following page hosts some simple
test cases where I could apply a pass/fail result.
http://lookout.net/test/uri/rfc3986-2.3.php
The next page hosts other test cases where I probably could use a
pass/fail as well.
http://lookout.net/test/iri/mixenc.php
But the following message I posted to the IRI working group shows some
test results where I wouldn't want to apply a pass/fail. Here I'd
rather capture the path from an HTTP GET request, as a string, and store
that. Then be able to compare that result across browsers.
http://lists.w3.org/Archives/Public/public-iri/2011Jul/0019.html
Chris Weber
>
>
> {
> 'test_one': 1,
> 'test_two: 2
> }
>
> Where 1/0 is pass/fail.
>
> Of course you can store integers there up to a much higher number, but
> for all our spec tests, the results are booleans like this.
I could make that work for some of the cases where there's a clear idea
of the expected result. But the goal with this was also to document
browser behavior where we don't really have a good reference for what's
expected. So instead of capturing a pass/fail result, I want to capture
how a given URI was parsed, resolved against a base, and generated - in
those cases the result would be an arbitrary string.
>
> You could definitely map handlers in the urls.py file to a
> HTTPRequestHandler (django's version of what you're talking about).
>
> Maybe you could send me an URL with an example and think about the
> format for the results as I outlined above.
> This might be easy enough for me to help you get started on and then
> you could just rock the rest.
>
That would rock. As an example - the following page hosts some simple
test cases where I could apply a pass/fail result.
http://lookout.net/test/uri/rfc3986-2.3.php
The next page hosts other test cases where I probably could use a
pass/fail as well.
http://lookout.net/test/iri/mixenc.php
But the following message I posted to the IRI working group shows some
test results where I wouldn't want to apply a pass/fail. Here I'd
rather capture the path from an HTTP GET request, as a string, and store
that. Then we'd be able to compare the result across browsers.
http://lists.w3.org/Archives/Public/public-iri/2011Jul/0019.html