Add browser test to keep track of browserify compability.

[eiriksm]

As discussed (or more like suggested) over at issue #1307: A browser test to make sure request can be built with browserify.

Last time it broke it was because one of the dependencies had a dependency which in turn used fs.readFile, which obviously does not work well in browsers. But those things are hard to spot unless it is automated.

So to sum it up. This is not for testing that all features actually work in the browser. Just to make sure it will bundle nicely.

One negative thing about this is the added dependencies and the added test build time. In addition to having more tests to "support" of course. For me the positive effects outshines this, but I can understand if someone might make that argument.

Anyway, this is the first take. Open for discussion, of course.

Oh, and thanks once more for making and maintaining this fantastic library. Have a nice day!

[coveralls]

Coverage decreased (-0.46%) when pulling 8e1b63d on eiriksm:feat/browserify-tests into 998831d on request:master.

[coveralls]

Coverage decreased (-0.37%) when pulling 754d48d on eiriksm:feat/browserify-tests into 998831d on request:master.

[simov]

@eiriksm the Travis build is failing, on a side note: I'm wondering why coveralls decreases the test coverage in case no new code is being added. It shows some red numbers, but not the actual lines of code.

Edit: that's probably due to code added between the last coveralls build

[eiriksm]

The build is failing because some of the dependencies seem to have dependencies which are declared with a caret (not supported on node .8).

I will probably make a more compact commit and push when the travis build is succeeding again.

I am guessing the coverage decrease is because the node .8 tests did not run. Maybe?

[coveralls]

Coverage remained the same when pulling 2db9f0a on eiriksm:feat/browserify-tests into 998831d on request:master.

[eiriksm]

Argh. Now it actually installs fine, but karma-browserify does not work on .8. Will have to look at it later I guess.

[coveralls]

Coverage decreased (-0.09%) when pulling 66b1755 on eiriksm:feat/browserify-tests into 998831d on request:master.

[eiriksm]

Yay.

Fun fact: the latest code and commit (that passed ) was written on the bus with my phone. Thats a first.

Ready for review. I'll squash some commits if it looks ok

[tschaub]

Instead of making a network request to api.github.com, you could add test fixtures locally and use Karma to serve these up locally.

[eiriksm]

Thats true, but I also wanted to make sure https and CORS worked in the browser, so that was the reason i picked api.github.com

[nylen]

Awesome stuff!

I agree with @tschaub that we should run test servers locally, but I'm good to put this in place first. As a future change we can mock a test HTTPS server and have it send back Access-Control-Allow-Origin: * for CORS.

Would like comment from other maintainers first though. @FredKSchott @simov @mikeal and anyone else

[nylen]

Whoops, I didn't mean to click the merge button yet 🐑 oh well, I guess we'll address any problems separately.

[simov]

👍 tests are good 🐺

[nylen]

@eiriksm we're having problems with requests to api.github.com from Travis (see this build log for example).

It's time to change the browser tests over to using a mock server. I know you can start PhantomJS with the --ignore-ssl-errors=true option to allow self-signed certs, but I'm not sure about the CORS piece. Want to help?

[eiriksm]

Sure. I'm on it