Sinon no longer throws when stubbing non-existent properties

[schreifels]

• Sinon version : 2.3.7
• Environment : OSX, Node 6 (Jest)
• Other libraries you are using: Mocha

What did you expect to happen?

When calling sinon.stub(obj, 'nonexistentProperty');, I would expect it to throw an error, e.g. "Attempted to wrap undefined property".

What actually happens

It does not throw (nor does it create a stub on the object at that property).

How to reproduce

Interestingly, if you use the deprecated 3rd argument to sinon.stub, it does still work, as shown in this example:

'use strict';

const assert=require('assert');
// const sinon = require('./lib/sinon'); // if checking out the sinon project
const sinon = require('sinon');

describe('sinon', () => {
  context('with the standard syntax', () => {
    it('throws when stubbing a non-existent property', () => {
      const obj = {};

      // FAIL: expected [Function] to throw an error
      assert.throws(() => {
        sinon.stub(obj, 'nonexistentProperty');
      });
    });
  });

  context('with the deprecated syntax', () => {
    it('throws when stubbing a non-existent property', () => {
      const obj = {};

      // PASS
      assert.throws(() => {
        sinon.stub(obj, 'nonexistentProperty', () => {});
      }, 'Attempted to wrap undefined property');
    });
  });
});

(I would have expected both tests to pass.)

[fatso83]

Thanks to your test I was able to automate the search for this using git bisect. This behavior has been consistent throughout the entire 2.x series and was introduced by PR #1297, and the change is mentioned in the list of changes.

From the discussion, I am not totally sure how it was decided we should go from throwing on non-existent properties to support stubbing them, but maybe @lucasfcosta remembers more? Anyway, this change was intentional and can't be reversed now (if so, use 1.x). The only thing I feel is an issue, is that this is a breaking change (as you show), that is not covered in the migration guide from 1.x to 2.x. That should be remedied.

[lucasfcosta]

Hi @schreifels, thanks for your issue!

As @fatso83 commented, this has been an intentional change in order to allow stubbing values, if I'm not mistaken.

Also, the reason why you are not getting a stub into the object itself when doing this is because you are not creating any behavior for it. By behavior I mean creating a fake getter or setter or even changing the descriptor's value by using the value behavior. However, IMO this is something that should be changed.

When creating stubs, even when we're not creating stubs for methods, they must replace the original property on the object.

---

TL;DR:

• IMO we should not throw for undefined properties because we do support stubbing them
• IMO we should indeed replace properties for the stubs being created for them even though they're not functions

I have this change ready right here and all tests pass. I will reopen this issue to get feedback on this new behavior and if everyone agrees I can just push this change and open a PR, it would take me only a few minutes.

[schreifels]

This seems to reasonable to me, thanks for the explanation @lucasfcosta and @fatso83!

[fatso83]

This is related to #1537, and we should close this issue if the conclusion is to fix that regression behavior.

[fatso83]

@lucasfcosta I have now digged down in this and it turns out we have never supported stubbing undefined properties. It always resulted in an exception, up until commit 278c2ce (which is when you added getters/setters). After this commit we still don't support it in a way, as no stub is created, but this is a regression and a bug in any case.

Now knowing this, this directly affects #1552 and friends, and I am now inline with the rest of the team that we should not support this in any way (sandbox or not). The bug introduced in 278c2ce should be fixed in any case.

Full testcase for verification:
https://github.com/fatso83/git-bisect-scripts/blob/master/sinon-1552-1508-git-bisect-script.sh

[fatso83]

Fixed in #1557. To be released shortly.