Sinon: Allow calling original function from stub

[dariomannu]

Seen related ticket #668 about spies, it would still be useful to stub a function only when called with certain parameters, allowing the call to reach to the original function otherwise.

sinon.stub(object, 'method')

  .withArgs('1')
  .returns('one')

  .callThrough() // default action, for any other arguments

sinon.stub(object, 'method')

  .withArgs('1')
  .returns('one')

  .withArgs(sinon.any.arguments) // same, with some syntactic sugar
  .callThrough()

One specific use case is to stub individual application configuration variables where they are accessed with a getter function (e.g.: nconf.get()).

Configuration objects can get quite large, so we would like to verify different behaviour in integration tests depending on a single configuration variable, but leaving the rest of the configuration untouched, whatever it is, as the rest of the application obviously still depends on it.

[fatso83]

Although I don't really see the big connection to #688, this issue is somewhat related to #988. After some tinkering with the feel of it, the API extension seems to make sense. Since we are struggling a bit with getting version 2 of Sinon out the door I don't think we'll focus much on creating new features, but you can create a PR against the master branch and we'll take it from there.

[thebarty]

I'd also love to have this feature for integrational test-scenarious.

For example: When sending out a batch of emails, let's simulate that Mailer.send throws an error for the 4th email. And still we might want to check that the content of the other emails was actually produced, which is why it is important that original call-parameters are passed thru to the original function when using callThrough.

Yasmine has a feature like this. I'd love to see it in sinon, too.

[thebarty]

Hi guys: thanks a lot for bringing this feature in!

When is there gonna be a new sinon-version on npm to use this in our projects? It's a real pitty that we can't use this yet

[fatso83]

if you _really_ cannot wait for another pre-release then either

• point your dependency in package.json to "sinonjs/sinon#master" (for Node and browser bundlers)
• build it and include it in your repo (for standalone browser bundles)

There was a world of working web software before NPM, you know ;-)

[nitinsurana]

I'm using Sinon 6.1.3 and getting TypeError: obj.withArgs(...).callThrough is not a function
Is this feature not out yet ?

[newhouse]

In case it helps others in the future, I just had an issue where my setup was something like this:

describe('test', function () {
  beforeEach(function () {
    sinon.stub(someThing, 'someMethod').resolves(true)
  })

  afterEach(function () {
    someThing.someMethod.restore()
  })

  // A bunch of other it() examples here...

  it('drives me crazy', function () {
    someThing.someMethod.callThrough()
    // Some code that expects someThing.someMethod to call the original, but in fact the stubbed `resolves('true')` was triggered
  })
})

In the end, the issue was this bit that is in the stub.callThrough() documentation (emphasis mine):

Causes the original method wrapped into the stub to be called _when none of the conditional stubs are matched_.

Because I had not specified any specific arguments in the stubbing taking place in the beforeEach, there were no calls to someThing.someMethod that did not match...so it was always using the stubbed resolution.

Perhaps this is a bit of poorly designed testing structure on our part...but, regardless, the quick "fix" was similar to some code in the original issue commment:

....
  it('does not drive me crazy', function () {
    // Redefines what to do with "any" arguments
    someThing.someMethod.withArgs(sinon.match.any).callThrough()

    // The rest of what I want to do...
  })
...