Subject: [http-state] A start at a test suite?

From: Daniel Stenberg <[email-masked]>
Date: Thu, 6 Aug 2009 16:33:02 +0200 (CEST)

(sending this again, my previous mail with this topic seems to have been eaten 
by an internet gremlin, possibly because I attached a zip file, that is now 
instead available at http://daniel.haxx.se/curl/cookie-test.zip)

Hey

Attached to this mail is a proof of concept of how it would look like if we'd 
use the curl test suite for testing cookie treatment of HTTP clients. It 
contains a test case number 9000 and the log files the curl test suite produces 
based on that.

This has the downside that to try this at home, you'll have to unpack the curl 
sources and run make in 'tests' dir to get it all setup. But since I already 
have this done and working, it is at least not a lot of extra work.

The upside is possibly that this could be setup to run over the internet so 
person X can run it for person Y whenever (s)he wants to try browser/client Z.

Then, you start the dumb test server:

$ ./tests/sws &

and off we go and test clients against it. You set your client to use 
localhost:8999 as proxy, and then you can try it out like this:

[warning, some curl options may not make sense to an untrained eye!]

$ curl -c log/cookies -L -x localhost:8999 http://127.0.0.1/9000

Or to try a regular browser against it, we'll just make a html file that 
contains:

   <a href="http://127.0.0.1/9000">test 9000</a>
   <a href="http://127.0.0.1/9001">test 9001</a>

After a single test has run, we can investigate the log files created in log/ 
to see exactly what the user agent sent and what it received. Like:

$ grep Cookie: log/server.response log/server.input
log/server.response:Set-Cookie: foobar=name; domain=127.0.0.1; path=/;
log/server.response:Set-Cookie: mismatch=this; domain=127.0.0.1; 
path="/silly/";
log/server.response:Set-Cookie: partmatch=present; domain=.0.0.1; path=/;
log/server.response:Set-Cookie: duplicate=test; domain=.0.0.1; domain=.0.0.1; 
path=/donkey;
log/server.response:Set-Cookie: cookie=yes; path=/we;
log/server.response:Set-Cookie: nocookie=yes; path=/WE;
log/server.input:Cookie: partmatch=present; foobar=name

Of course since this all is still a little fuzzy, we can't tell for sure what 
behavior is correct. I figure the 'log/server.input' file is what is going to 
be interesting for each test, at least assuming we get a bunch of tests written 
and a bunch of clients ran against it.

I don't mean to imply that this is something incredibly clever or anything, 
just that it already exists and works for us in the curl project and it could 
be a way to get some tests going rather easily.

-- 

  / daniel.haxx.se

---

From: Adam Barth <[email-masked]>
Date: Fri, 7 Aug 2009 00:10:15 -0700

Thanks for sending this along.  I tried to get this to work, but it
seems a bit more complex than we need at the moment.  In particularly,
the test harness appear a bit tricky to extricate from the rest of the
CURL source tree.  However, these appear to be well-design test cases
that we should definitely use!

Adam

On Thu, Aug 6, 2009 at 7:33 AM, Daniel Stenberg<[email-masked]> wrote:
> (sending this again, my previous mail with this topic seems to have been
> eaten by an internet gremlin, possibly because I attached a zip file, that
> is now instead available at http://daniel.haxx.se/curl/cookie-test.zip)
>
> Hey
>
> Attached to this mail is a proof of concept of how it would look like if
> we'd use the curl test suite for testing cookie treatment of HTTP clients.
> It contains a test case number 9000 and the log files the curl test suite
> produces based on that.
>
> This has the downside that to try this at home, you'll have to unpack the
> curl sources and run make in 'tests' dir to get it all setup. But since I
> already have this done and working, it is at least not a lot of extra work.
>
> After a single test has run, we can investigate the log files created in
> log/ to see exactly what the user agent sent and what it received. Like:
>
> log/server.response:Set-Cookie: duplicate=test; domain=.0.0.1;
> domain=.0.0.1; path=/donkey;
> Of course since this all is still a little fuzzy, we can't tell for sure
> what behavior is correct. I figure the 'log/server.input' file is what is
> going to be interesting for each test, at least assuming we get a bunch of
> tests written and a bunch of clients ran against it.
>
> just that it already exists and works for us in the curl project and it
> could be a way to get some tests going rather easily.
>
> --
>
>  / daniel.haxx.se
> _______________________________________________
> http-state mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-state
>