Support Sinon 2 about sinon-bluebird HOT 6 CLOSED

Quick update. I just checked out the migration docs for Sinon v5 and sinon root itself is now a sandbox meaning that you should hopefully only have to call sinon.usingPromise(bluebird.Promise) one time at the top of your file test files. I haven't tried it yet, but that's how sandboxes worked and since sinon root is now by default a sandbox that would make sense.

http://sinonjs.org/guides/migrating-to-5.0

from sinon-bluebird.

Yeah, I am not surprised. Having said that, in [email protected] there is now native built-in promise methods with the same names. If you want bluebird specific methods, you just call usingPromise with sinon and provide bluebird as the specific promise implementation. I fully expect this module to die now that sinon has builtin support.

Per the Sinon 2.x docs:

Resolves

stub.resolves(value);
Causes the stub to return a Promise which resolves to the provided value.

When constructing the Promise, sinon uses the Promise.resolve method. You are responsible for providing a polyfill in environments which do not provide Promise. The Promise library can be overwritten using the usingPromise method.

Since [email protected]

Rejects

stub.rejects(value);
Causes the stub to return a Promise which rejects with the provided exception object.

When constructing the Promise, sinon uses the Promise.reject method. You are responsible for providing a polyfill in environments which do not provide Promise. The Promise library can be overwritten using the usingPromise method.

Since [email protected]

from sinon-bluebird.

usingPromise seems pretty inconvenient to use though, if you have to call it for every stub you create. That's why I was hoping this library would make it easy to make sinon use bluebird with just a line of import code.

from sinon-bluebird.

Hey sorry for not getting back to you sooner. My first assumption, ironically, was that you were misunderstanding how to use usingPromise method, then I dug a little deeper and realized, I completely misunderstood it. No idea why they thought making a user call usingPromise on every single stub or sandbox call was a good idea. I get the desire to not introduce global state, but Promise itself is a global...no way to avoid that.

Yeah, I will definitely have to update this library then. Maybe this weekend. So sad ☹️

from sinon-bluebird.

Dug a little deeper and there is a slightly more global solution. Just use sandboxes to create your stubs (or anything else). It is an extra line of code but should work as expected.

const sinon = require('sinon')
const bluebird = require('bluebird')

describe('Some Test Case', function() {
  let sinon
  before(function() {
   // create sandbox and all stubs/spies/etc will use bluebird promises
   sandbox = sinon.createSandbox().usingPromise(bluebird.Promise) 
   sandbox.stub()
   sandbox.spy()
  })
  after(function() {
    // no need to call restore on stubs as sandbox does that for you
    sandbox.restore()
  })
})

Sandbox docs are here: http://sinonjs.org/releases/v4.5.0/sandbox/
Sandboxes are definitely the direction I would go. Not the best for legacy apps, but if your updating to sinon 2.x your probably updating other test code as well. Sandboxes are probably the future of sinon.

from sinon-bluebird.

Yeah fair enough. Still feels like a lot of boiler plate if you do this fore every test file. Anyway, thanks for considering it.

from sinon-bluebird.