Remove support for stubbing undefined props

[fatso83]

Purpose

This removes support for stubbing undefined properties, aligning the behavior with how sandbox stubbing works. The reasoning behind not allowing this is

stubbing non-existing own properties is likely to lead to mistakes in tests, where the test passes because the author mistyped the name of the existing property they were aiming to stub

Background

This was a longer discussion that can be found in the
issues #1508, #1552 and #1537 - and internally amongst the core team.

Support for stubbing props using get()/set() was added in #1237
and also worked for undefined properties.

This type of behavior (stubbing undefined props) has been
explicitly disabled for sandboxes, so in order for Sinon to
behave in a consistent way, we should do the same here.

This change will bring normal stubs back to how it has
used to be historically, and will make sandbox stubs
and normal sinon stubs behave the same.

It might break things for people relying on the behavior
that has been present since Sinon 2.0, but it should
make things more reliable going forward.

[fatso83]

The alternative to removing this functionality is the inverse of this:

• remove the restriction introduced for sandboxes in 3.1 (Sandbox throws error 'cannot stub non-existent own property' #1537)
• fix the stub that is being produced (the reason for sinon.stub(object, "missingMethod") silently fails #1552 is that the stub is only produced at the point we call set(...) - this could be done earlier)

[mroderick]

You can count on me to pretty much always err on the side of stricter use of languages and apis, and this is another one of those cases.

I vote 👍

[mroderick]

@sinonjs/sinon-core any objections to merging this?

[fatso83]

@mroderick Only the objections raised in this other issue. Thought it might be a nuisance to have two major releases in short succession, but it's not a big thing, so you might as well. There's not like there is a PR out there for the factory function refactor.

[mroderick]

@mroderick Only the objections raised in this other issue. Thought it might be a nuisance to have two major releases in short succession, but it's not a big thing, so you might as well. There's not like there is a PR out there for the factory function refactor.

I don't see having several MAJOR releases as a big deal, as long as their changelogs are small at least :)

[Glogo]

This may be unrelated to this issue, but for those that have the same problem as me with version 4 now.
Instead of doing this:

sinon.stub(obj, 'yourMethod', () => Promise.resolve('whatever'))

you do:

sinon.stub(obj, 'yourMethod')
  .returns(() => Promise.resolve('whatever'));

[fatso83]

@Glogo, actually we have had promise support for several versions, so it is even shorter:

sinon.stub(obj, 'yourMethod').resolves('whatever');

[paulmelnikow]

stubbing non-existing own properties is likely to lead to mistakes in tests, where the test passes because the author mistyped the name of the existing property they were aiming to stub

Maybe; or maybe it's deliberate: #1537 (comment)

[cphoover]

Why was support for this removed?

As others have said adding

window.someKey = 'someValue';
// ... testCode here
delete window.someKey

is problematic if you have multiple differing values between tests, or it may be defined as something else in the future. With sandbox.restore we know we cleanup after ourselves so if that value is defined in the future we shouldn't run into issues. I think it makes sense to allow stubbing undefined properties maybe add another method if you are worried about this.