Cache HTTP requests in tests

[rstacruz]

Tests are very slow because they simulate ied install:

  install
    ✓ should install browserify@12.0.1 (19685ms)
    ✓ should install tape@4.2.2 (8569ms)
    ✓ should install express@4.13.3 (16876ms)
    ✓ should install mocha@2.3.4 (4246ms)
    ✓ should install lodash@3.10.1 (4019ms)
    ✓ should install gulp@https://github.com/gulpjs/gulp/archive/4.0.tar.gz (25571ms)
    ✓ should install grunt@0.3.1 (13590ms)

This speeds it up considerably by caching HTTP requests:

  install
    ✓ should install browserify@12.0.1 (3344ms)
    ✓ should install tape@4.2.2 (420ms)
    ✓ should install express@4.13.3 (613ms)
    ✓ should install mocha@2.3.4 (379ms)
    ✓ should install lodash@3.10.1 (457ms)
    ✓ should install gulp@https://github.com/gulpjs/gulp/archive/4.0.tar.gz (7444ms)
    ✓ should install grunt@0.3.1 (1280ms)

This does it by caching the HTTP requests into the repo itself. It comes with 25MB of data Fixtures are .gitignored, so this only affects running the tests locally on your machines.

[just-boris]

I don't think that keep such a lot of files in the repository is good. I'd recommend you to keep this integration tests as is, but also add some unit tests on fetch.js module. Now we have got a nock - it is an HTTP-mocking library, that allows you to write this kind of tests with ease.

Then you can not to run integration tests every time if you considering them very slow for you (btw, in Travis they run two times faster than your results)

[rstacruz]

How about a middleground — let's keep sepia but gitignore fixtures? this way, local tests will be fast without the bloat.

I'm currently using the integration tests to quickly develop a patch for #61 :)

[rstacruz]

Okay, done as that. Fixtures are now not committed to the repo, so local runs will be cached perfectly without extra bloat :)

[alexanderGugel]

Not sure about that one. Realistically we should mock out the entire registry anyways. Was thinking about using something like this: https://github.com/npm/npm-registry-mock

Thoughts?

[rstacruz]

i think it's pretty cool that the tests run against the actual registry. that way we can uncover strange test cases that appear in actual packages. if any package is reported to be defective, we can just add it in... which we can't do on npm-registry-mock.

[alexanderGugel]

Can you rebase? Happy to merge.

[rstacruz]

here we go!

[rstacruz]

btw we can do this too:

# travis.yml
cache:
  directories:
  - node_modules
  - fixtures

but i'm not sure how that'll interact with having multiple node.js versions.

[alexanderGugel]

Uhh hmm.. they should run in isolation I think... so that shouldn't be an issue...

[alexanderGugel]

Thanks!