Sinon: Stub get does not work with sandbox stub

Created on 10 May 2017  路  6Comments  路  Source: sinonjs/sinon

stub().get() used to stub property getters, works well with sinon.stub, but I get _get is not a function_ with sandbox.stub.

Also, slightly related, .get does not exist on the typescript definition _@types/sinon_

Feature Request major

Most helpful comment

Hi @fatso83, that's because we discussed that through DM's on Twitter.

I also explain why we can't do this on this post. Basically, this issue is a duplicate of #781.

Since we've had many changes in the codebase since then, these are my new thoughts on how we could solve this.

Since a sandbox extends a collection and a collection's stubs do not take a third value as argument anymore we will not have the same problem as before because now we cannot mistake a third argument that is an object for the new value of that property or a property descriptor, as I've described in the previously mentioned post.

This also means we can now have a uniform API and add get and set methods to the stubs created by sandbox.stub.

Also, by looking at the collection.stub method, I can't see why we are not reusing the stub function since we're basically duplicating lots of logic and thus making things more error prone in order to achieve the same goal. I think we could just use the stub function and add it to the collection itself.

If you all agree on this I can refactor sandbox.stub the way I described above and fix this.

All 6 comments

I have the same problem, wanted to switch to using the sandbox and expected stubs to work the same but there is no get function on the sandbox. Is there another method to accomplish the same functionality?

@lukiano I did some digging through the code and you can stub out properties, just with a different syntax. Quite confusing and would be nice if this was consistent.
So with sinon:
sinon.stub(myObject, 'myProperty').get(() => 'stubbedValue')
and with sandbox:
sandbox.stub(myObject, 'myProperty', 'stubbedValue')

@lucasfcosta, do you remember why we chose not to align these two APIs? There was something ... but the details elude me.

Hi @fatso83, that's because we discussed that through DM's on Twitter.

I also explain why we can't do this on this post. Basically, this issue is a duplicate of #781.

Since we've had many changes in the codebase since then, these are my new thoughts on how we could solve this.

Since a sandbox extends a collection and a collection's stubs do not take a third value as argument anymore we will not have the same problem as before because now we cannot mistake a third argument that is an object for the new value of that property or a property descriptor, as I've described in the previously mentioned post.

This also means we can now have a uniform API and add get and set methods to the stubs created by sandbox.stub.

Also, by looking at the collection.stub method, I can't see why we are not reusing the stub function since we're basically duplicating lots of logic and thus making things more error prone in order to achieve the same goal. I think we could just use the stub function and add it to the collection itself.

If you all agree on this I can refactor sandbox.stub the way I described above and fix this.

@lucasfcosta, I think that makes plenty of sense. If you have the time, then please!

@fatso83, for sure!

I'll love to work on this refactor and a few other related improvements while eating some sushi this weekend 馃槃

Was this page helpful?
0 / 5 - 0 ratings