Better unit tests

[SamyPesse]

👷 WORK IN PROGRESS 🚧

This PR adds more (and better) unit tests to Nuts. Basically download and updates will be correctly unit tested to avoid breaking changes when trying to contribute to the repository.

This PR will also add standard HTTP status codes to responses, and fix #56.

I was hoping to move code to ES6 (cleaner code, especially for classes) and use Babel before npm releases, but I can't find a solution to make it work correctly while supporting the Heroku Deploy button (I'm open to ideas!).

I'll release a new version 🚀 as soon as all endpoints are correctly tested, and once I'm sure merging #95 did not break Nuts for GitBook and other devs.

XOXO 💕

[SamyPesse]

I fixes #95, which was breaking the whole update system (stable will have been updated to unstable, etc).

@mzmousa can you look at the spec in test/update.js? And let me know if this is what you are expecting from update channels.

[SamyPesse]

@jsloyer Since you are also interested in update channels, please look at the spec.

I want to be sure that we all agree on update channels:

• /update/channel/beta should update the user to the latest beta or stable version
• /update/channel/alpha should update the user to the latest alpha or stable version (maybe beta too?)
• /update should update the user to the latest stable version (but accept unstable version if using one).

[mzmousa]

@SamyPesse This is the way I'm currently using it - I'm most just following how Squirrel-updates-server does it since it worked out so conveniently: /update/channel/[alpha | beta] should update to the user to the latest [alpha | beta] version /update/channel/stable should update the user to the latest stable version, but I think I agree with /update also updating to latest stable.

should update the user to the latest beta or stable version

What do you mean by this, specifically? I think I agree with having the stable version update as a fallback if something were to go wrong on the alpha or beta versions, but would we be able to have an error or something sent back in the JSON to specify why the fallback occured? :)

[alexstrat]

I agree that /update should update the user to the latest stable version, and not any version — that's not the behavior implemented now on master. Should I open a separate PR to fix this, or are we close to merge this one? Good job for the unit-test 👍 btw :)

[alexstrat]

An other case I realize now: if you had a version 1.0.0-beta (ending-up in channel beta) and you release a version 1.0.0 (that ends up in channel stable then), shouldn't we expect that /update/channel/beta/osx/1.0.0-beta leads to 1.0.0? It does not look to me that's the implemented behavior.

As a comparison, this is exactly the behavior implemented in electron-release-server: see here and here.

[julienma]

Hey @SamyPesse, @alexstrat, I've tested this PR and it fixes the issue I had on /update (cf. https://github.com/GitbookIO/nuts/issues/102#issuecomment-299855123 and https://github.com/GitbookIO/nuts/pull/95#issuecomment-285559009).

I'll use this PR as my main update server (as master does not work for me), but am of course wondering why it has not already been merged. What's missing to get it stable (and merged)?

[loprima-l]

Hi, I merged the project to a new repo to start maintain it, I would be glad if you can put your pull request here : https://github.com/loprima-l/nuts-2