Sinon: exposing wrappedMethod

[tonylukasavage]

I have a use case where I need to stub a function, but only under a certain circumstance. Essentially, I need a function to execute normally until a certain condition is met, and then I need to stub it. I could do this easily if the wrappedMethod was exposed, rather than internal to the module.

So basically I'm asking if there's a fundamental reason that wrappedMethod is not exposed? If not, would you be open to a PR that exposed it on spies, stubs, and mocks?

[fatso83]

I am having a problem understanding why you cannot do this already?

var originalFunction = myLib.functionFoo;
var stub = sinon.stub(myLib, 'functionFoo', function() {

if(caseIsMet)
    stub.apply(mylib, arguments);
else {
    originalFunction.apply(mylib, arguments);
}

[tonylukasavage]

Some code would probably better explain. It's not a big deal, I was more wondering if there was an explicit reason _not_ to expose it.

// a.js
module.exports = function() {
  api.func(1);
  api.func('badvalue');
  api.func(2);
}

// stubbing for a.js test (how I do it now)
var _func = api.func;
sinon.stub(api, 'func', function(val) {
  if (val === 'badvalue') { 
    throw new Error('some_error'); 
  } else {
    _func.apply(api, arguments);
  }
});

// stubbing for a.js test (how I'd like to do it)
var stub = sinon.stub(api, 'func', function(val) {
  if (val === 'badvalue') { 
    throw new Error('some_error'); 
  } else {
    stub.wrappedFunction.apply(api, arguments);
  }
});

[fatso83]

OK, I get what you want, and I have a feeling this comes up from time to time, but I don't remember where I saw the last discussion on this... For a more recent example, instance #989 seems like essentially a duplicate of this. It is not a direct duplicate, but the suggested API would probably achieve what you intend to accomplish. Am I right? That would be a cleaner API IMHO.

[fatso83]

To elaborate, your example would then be written:

sinon.stub(api,'func')
     .withArgs('badvalue')
     .throws(Error)
     .callThrough()

It should be mentioned that this would only apply to a subset (probably the majority) of possible conditions as it just filters on equality of arguments passed, and you cannot pass arguments to the error constructor.

It is not unthinkable that it could make sense to expose the original function to support more elaborate cases. As to why it has explicitly been avoided in the past is a detail I don't know ...

[lucasfcosta]

Hi friends!

I think we can close this one since we've got callThrough due to #1234 and now the wrappedMethod is exposed, as you can see in this line.