Closed
Bug 545457
Opened 13 years ago
Closed 7 years ago
Get http-state tests running as unit tests
Categories
(Core :: Networking: Cookies, defect)
Core
Networking: Cookies
Tracking
()
RESOLVED
INCOMPLETE
People
(Reporter: dwitte, Unassigned)
Details
Attachments
(1 file)
4.59 KB,
patch
|
Details | Diff | Splinter Review |
+++ This bug was initially created as a clone of Bug #542974 +++ See https://bugzilla.mozilla.org/show_bug.cgi?id=542974#c5. Many of the http-state tests require testing from a given domain. The http-state tests achieve this by having entries in /etc/hosts; since we clearly can't do that, the next best thing is to run them as mochitests with appropriate servers for each test. This will let us test arbitrary origins separately in each test; see http://mxr.mozilla.org/mozilla-central/source/build/pgo/server-locations.txt for details. I'll post a patch to show the general idea.
Reporter | ||
Comment 1•13 years ago
|
||
Actually, meh. Mochitests are a bit overcomplicated for this. Let's just do it with xpcshell tests, using the nsICookieService interface directly. This doesn't quite get us end-to-end testing, but it's pretty damn close. Here are the two sample tests - pretty easy to generate with a little python script. The 'uri' variable can obviously be adjusted depending on what kind of subdomain tests you want; making an 'https' URI will similarly allow testing of the 'secure' attribute; calling {set,get}CookieString instead of {set,get}CookieStringFromHttp will allow testing of 'document.cookie'-ish behavior wrt 'httpOnly'. If you want more detailed poking at the internal cookie structures than getCookieString{FromHttp} can provide, this can easily be accomplished using the nsICookieManager{2} interface.
Updated•7 years ago
|
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•