Typings test

[smartclash]

Typings tests for public facing API would be now written inside the test-types/ folder. It uses TSD and jest-runner-tsd.

We still haven't covered every API available. This is at it's start and we need to get more inputs on our approach. We'd like to know if

• The way tests are split is okay or not?
• The place where tests are placed is okay or not?

... and suggestions would be really good too :)

We are now using jest's projects to use the custom runner and test the types.

Builds are still failing because jest-runner-tsd is not published to NPM and can be published only after the PRs are merged in TSD.

TODOs:

• Get reviews / suggestion.
• Implement the suggestions.
• Fix the ESLint issues.

[jevakallio]

@smartclash, I left a couple of comments -- the main one being, that when we are testing types, it would be ideal not to be testing for any. Kind of defeats the point?

I understand that the TSD assertion tests do add value even when we don't test the return type, as it does test against the function parameters and reports any type errors to jest.

I'd ask Simen for feedback on this ASAP. In order to help him give good feedback, I'd improve the PR description explaining what you are asking feedback on -- overall approach, not individual tests. Also, I would explain that this is not full type coverage yet, and you intend to do that after the approach has been validated.

Personally, if you don't have anything else to do, I'd not wait any longer for feedback and proceed with writing tests for further APIs using this approach.

[smartclash]

@smartclash, I left a couple of comments -- the main one being, that when we are testing types, it would be ideal not to be testing for any. Kind of defeats the point?

I understand that the TSD assertion tests do add value even when we don't test the return type, as it does test against the function parameters and reports any type errors to jest.

I'd ask Simen for feedback on this ASAP. In order to help him give good feedback, I'd improve the PR description explaining what you are asking feedback on -- overall approach, not individual tests. Also, I would explain that this is not full type coverage yet, and you intend to do that after the approach has been validated.

Personally, if you don't have anything else to do, I'd not wait any longer for feedback and proceed with writing tests for further APIs using this approach.

@jevakallio, the functions itself return any type. And so, we've also used any at tests too :)

[SaurabhAgarwala]

@SimenB please review this PR and let us know if the approach we are following is good or requires any changes?

This PR is related to jestjs#8794

[SimenB]

Yeah, I like this approach! I'd like to see some tests for type errors tho - missing arguments and arguments with wrong type etc.

I wonder if we should just run this as part of the Node CI / Running TypeScript compiler & ESLint (pull_request) workflow and not all tests, but we can tweak that later.

[SaurabhAgarwala]

Moved to #jestjs#10407.

Merged there. Closing this.

[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.