I experience a lot of pain trying to test my javascript for use in a browser. Some of this has been relieved by categorizing the flavor of code and testing each flavor differently. I can usually break down browser code flavors into the following:

1. Synchronous utility code
2. Interact with the DOM (read, add event listener, fire event, write)
3. Handle some event
4. Make some server request

If your code isn’t separating these things, it probably should. This is how I test each of these flavors:

1. This calls for standard unit testing, test input -> test output. These should make no XHR calls, select arbitrary nodes from the DOM at large, and fire no events unless that is ALL they do and its pretty clear from the function/class name they do so. If your test for this is unmanageable, odds are your function is doing too much.
2. These are basically view tests. I’d recommend using jsdom to mock the DOM during these test. Firing events should also be part of your integration tests as one event can override another, stop propagation early, or forget to stop event propagation without being caught here.
3. These are asynchronous tests. Similar to unit testing, you just pass in an event with test args and make sure it calls the right function stubs/events. I like how mocha handles async testing via a timeout. You can also use this timeout to optimize for speed.
4. Use sinon to stub XHR requests. If you use websockets, stub them as well (I haven’t found a sinon for websockets yet, but it should be easy enough). You can pass in test input, test the message passed to the xhr/websocket stub, and wala! Note: please don’t put logic in XHR callbacks. Instead, please fire and trigger an event. Testing the server response should be part of the server test code. I’d love to share the same request/response data for callback testing and server testing, but I haven’t done this before so I can’t say how it works out.

network-accessible storage + ad hoc networks  === Internet 3

• There aren’t centralized server apps or client apps, but peer apps. 
• You store your peers data and they store yours. 
• You communicate directly with devices close to you. 
• Access to the network is free.
• The internet is only used to ‘jump’ across other dense networks.
• Most of your stuff is on the peer network.
• If you live in a dense place like a city, no need for a cell plan, as you use less battery connecting to a nearby peer device rather than a tower 1/2 mile away.
• The network doesn’t go down when the power does.
• Some people are gateways to the wider internet and charge you to jump out— but you set your price and if someone else nearby offers it lower you use them instead. 
• You’ll never pay for a local phone plan again.
• You can broadcast messages to just people nearby.
• You can download apps from your peers or send them.
• You can share music and videos to people next to you without any authorization. 
• When you are at a crowded event you get better signal, not worse.
• You can cache pages looked at while browsing internet on your device so others can access it free or faster (but only if you want to).
• Banks issue you codes that are equivalent to cash. You sign it and send it to the receiver with a description of what you are buying. They can’t cash it without verifying their own identities, yours, and the description.
• Verifying identity will likely be the biggest industry, and may be municipal or for-profit driven.

It would be an interesting world and it’s possible now.

This is more a brainstorming session than anything else. J2EE has been killing me of late and I’ve been trying to explain to coworkers how Node.js/Connect and Ruby/Rails work differently

HTTP Server

1. You should always be able to access the response and request.
2. You should always have access to a session identifier if it exists and be able to remove it.
3. Resource Mapping should consist of mapping urls to resources. A resource should be a static file or a controller. In order to support generic controllers, variables may be extractable from a URL. Static resources should be cached and listened to for changes!
4. There should be an easy way to listen and post to a web socket in addition to subscribing to open/close events
5. There should be a way to intercept a static file or controller request

The above rules should be the sole extent of an Http Server.

HTTP Utilities:

1. There should be an easy way to extract HTML Form data from a request.
2. There should be an easy way to extract POST data from a request.
3. There should be an easy way to add cookies to a response and retrieve cookies from a request.
4. There should be an easy way to urlize and de-urlize a string

Container Utilities:

1. There should be an easy way to extract JSON and XML from a String
2. There should be an easy way to stream bits in from a request and out to a response
3. There should be an easy way to Map a Dictionary of List of String to and from HTML form data
4. There should be an easy way to associate data with a session, and delete a session

In apache 2.2.22,

 # yay 
 <Proxy balancer://yay stickysession=JSESSIONID failonstatus=500,501,502,503>
 BalancerMember http://webqa1.somewhere.com:8400/yay/ retry=10 route=webqa1
 BalancerMember http://webqa2.somewhere.com:8400/yay/ retry=10 route=webqa2
 </Proxy>
 ProxyPass /reslife/ balancer://yay/ 
 # YAY 
 <Proxy balancer://YAY stickysession=JSESSIONID failonstatus=500,501,502,503> 
 BalancerMember http://webqa1.somewhere.com:8400/YAY/ retry=10 route=webqa1 
 BalancerMember http://webqa2.somewhere.com:8400/YAY/ retry=10 route=webqa2 
 </Proxy> 
 ProxyPass /YAY/ balancer://YAY/ 

Will produce a balancer called “balancer://yay” with 4 workers mapped to both /YAY and /yay. Requests will randomly stick to one or the other. Fun bug/feature of the day.

“Both of them recognized a cultural wrong, they envisioned a world without that wrong, and they dedicated themselves to fighting for a principle.”

Unsupported

• iPad1 Safari - Mozilla/5.0 (iPad; CPU OS 5_0_1 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Version/5.1 Mobile/9A405 Safari/7534.48.3
• Opera - Opera/9.80 (Macintosh; Intel Mac OS X 10.7.3; U; en) Presto/2.10.229 Version/11.61
• iPad2 Safari - Mozilla/5.0 (iPad; CPU OS 5_1 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Version/5.1 Mobile/9B176 Safari/7534.48.3
• iPhone Safari - Mozilla/5.0 (iPhone; U; CPU iPhone OS 4_3_5 like Mac OS X; en-us) AppleWebKit/533.17.9 (KHTML, like Gecko) Version/5.0.2 Mobile/8L1 Safari/6533.18.5
• iPhone Opera - Opera/9.80 (iPhone; Opera Mini/6.5.1.23995/27.1366; U; en) Presto/2.8.119 Version/11.10

Supported

• Chromium - Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.11 (KHTML, like Gecko) Ubuntu/11.10 Chromium/17.0.963.79 Chrome/17.0.963.79 Safari/535.11
• Chrome - Mozilla/5.0 (Windows NT 6.1) AppleWebKit/535.11 (KHTML, like Gecko) Chrome/17.0.963.79 Safari/535.11
• Firefox 11 - Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20100101 Firefox/11.0
• IE9 - Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)
• IE7 - Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; InfoPath.3)
• OSX 10.7 Safari - Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_3) AppleWebKit/534.54.16 (KHTML, like Gecko) Version/5.1.4 Safari/534.54.16
• Android browser - Mozilla/5.0 (Linux; U; Android 2.3.3; en-us; DROIDX Build/4.5.1_57_DX5-35) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1

Source: https://gist.github.com/2172114