fix(jest-mock): spyOn should support 0 key in objects (#14077)

[octaharon]

Summary

jest.spyOn previously throwed when applied to a method that is referenced by 0 key of the target module/object, thus being incompatible with design patterns, that rely on Enum indices, and Array-like objects.

See #14077

Test plan

enum IndexedKeys {
    A,
    B,
    C
}

const DynamicDispatchObject:Record<IndexedKeys,CallableFunction>={
    [IndexedKeys.A]:()=>{},
    [IndexedKeys.B]:()=>{},
    [IndexedKeys.C]:()=>{}
}

// Doesn't throw anymore, works as intended
const spiedFunction = jest.spyOn(DynamicDispatchObject, IndexedKeys.A);

[mrazauskas]

In a way these message (and also some of "Cannot spy on the method property because it is not a function" below) are somewhat misleading. How about reworking the whole check logic like this or so:

if (methodKey == null) {
  throw new Error('No property name supplied');
}

if (accessType) {
  return this._spyOnProperty(object, methodKey, accessType);
}

const original = object[methodKey];

if (!original) {
  throw new Error(
    `Property ${String(methodKey)} does not exist in the provided object`,
  );
}

[mrazauskas]

E.g., spyOn getters or setters has property existence check:

https://github.com/facebook/jest/blob/15af9b3b6f53a4f2f2e39d328eb6ef9f46ba91c4/packages/jest-mock/src/index.ts#L1268-L1270

[octaharon]

If you ask me, I have no objections. But the messages you refer to were implemented back in 2018 (#5107) for reasons I'm not aware of, and changing those go beyond the scope of fixing the related bug and this PR, I believe. Feel free to do it in a separate PR though, but please note that the code you suggested will not fix the bug and can possibly create more bugs, because methodKey==null is an incorrect way to check for an object key, since it's true only for undefined and null, at least according to MDN

[mrazauskas]

since it's true for methodKey===0

Not sure I follow this. methodKey == null would exclude only undefined and null, hence the message 'No property name supplied' is correct. This message does not sound correct if user passed '' or NaN as a methodKey. Do I miss something?

[octaharon]

That message for sure doesn't sound correct, but still it was there for 5 years, and I don't believe I'm in position to decide the way it should be changed.

I personally don't see how null and '' are different in this context, for instance, yet getting a message like that would not help me much if I've passed a variable as the second argument (i.e. "supplied" something), which could possibly be any of the above. If I was to make a statement, I'd say if (!object[methodKey]) is enough to cover all the edge cases here, resulting in the same error, i.e. Method ${methodKey} doesn't exist in the provided object, assuming spyOn expects a function. Also I don't believe testing for particular error strings is a good approach in general, at least when they are literal strings instead of shared constants. The aforementioned tests I've implemented do match the existing behaviour, which was not covered before.

However, I don't mind putting in a few extra lines of code, but if are willing to take the responsibility for those changes, please provide the exact requirements.

[mrazauskas]

Feel free to do it in a separate PR though

See #14087

[github-actions]

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.