Add spyOn function introduced in Jest 19

[alexjoverm]

Please fill in this template.

• Make your PR against the master branch.
• Use a meaningful title for the pull request. Include the name of the package modified.
• Test the change in your own code. (Compile and run.)
• Follow the advice from the readme.
• Avoid common mistakes.
• Run tsc without errors.
• Run npm run lint package-name if a tslint.json is present.

If changing an existing definition:

• Provide a URL to documentation or source code which provides context for the suggested changes: <http://facebook.github.io/jest/docs/jest-object.html#jestspyonobject-methodname>
• Increase the version number in the header if appropriate.
• If you are making substantial changes, consider adding a tslint.json containing { "extends": "../tslint.json" }.

[dt-bot]

jest/index.d.ts

to authors (@pspeter3 @vsiao @NoHomey @jwbay @asvetliakov). Could you review this PR?
👍 or 👎?

Checklist

• pass the Travis CI test?

[asvetliakov]

I'd suggest this

function spyOn<T extends {}, M extends keyof T>(object: T, method: M): MockInstance<T[M]>;

Also return type typeof jest is wrong. jest.spyOn returns mock/spy instance not the global jest object

Better T extends object but this require TS 2.2 and PR won't be merged until 4-6 weeks passed

[alexjoverm]

@asvetliakov you're right about the return type, my mistake.

About the other thing, I see the benefit so you assure is an existing property of that object. Does that take into account custom properties? Because I assume T extends {} creates a new Object type.

Anyway, if that'll take that much time, I could always create another PR by that time, but at least if we merge this now spyOn will be usable in ts-jest.

[asvetliakov]

T extends {} infers type from parameter, so it will be your type that you had passed into spyOn. keyof T will filter properties for this type only.

[alexjoverm]

I've also realized I didn't put it in the right alphabetical order.

What about the new change? It's not as good as what @asvetliakov but it will work right now since doesn't need the keyof operator.

function spyOn<T extends {}>(object: T, method: string): Mock<T>;

[asvetliakov]

Why you dislike keyof operator 😄 ?

[alexjoverm]

Sorry, got confused. I do like keyof operator and knew it is part of TS 2.1, but I assumed extends was there before 😂

Well, to return Mock<T> is necessary to specify the T but true it doesn't need to extend {}.
I see the fn function implementation also uses extend {}.... So couple of questions here:

Is it ok the following implementation? And will it take long to get merged?

function spyOn<T>(object: T, method: string): Mock<T>;

If not, then should we go for what you @asvetliakov?

function spyOn<T extends {}, M extends keyof T>(object: T, method: M): MockInstance<T[M]>;

And, would it matter too much the return type to be Mock or MockInstance?

Sorry for these many questions but I'm not a TS expert and is my first PR to this repo 😄
Thanks for the time :)

[mhegazy]

@alexjoverm can you please refresh the PR against master.

[jwbay]

@alexjoverm The second option in your last post is definitely preferable. About MockInstance vs Mock, the difference is that Mock has construct and call signatures. If spyOn returned a Mock type, you'd able to do this

const spy = jest.spyOn(obj, 'foo');
spy(); //call
new spy(); //construct

But I don't know when it makes sense to call your own spy in a test. And if you really wanted to, you could just call the method directly on the object instead.

Something this PR is missing though is mockRestore. See the example test here: http://facebook.github.io/jest/docs/jest-object.html#jestspyonobject-methodname. Although it can be called on every mock, it may be confusing since it's a no-op on everything except spies. I would suggest this for spyOn's return type.

interface SpyInstance<T> extends MockInstance<T> {
  mockRestore(): void;
}

[alexjoverm]

@mhegazy @jwbay Wow, thanks for that big help.

Totally have missed the mockRestore. I'll update it with your suggestions as soon as I can, and probably will do a git rebase to clean up the history.

[alexjoverm]

Ok done. Since hundreds of commits are in between because of the merge, I preferred not to rewrite history, just in case it breaks something for others.

[mhegazy]

@jwbay mind taking another look.

[jwbay]

👍