Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Integrate a runner and reporter for testing types #4

Closed
1 of 4 tasks
smartclash opened this issue Jun 15, 2020 · 9 comments · May be fixed by #7
Closed
1 of 4 tasks

Integrate a runner and reporter for testing types #4

smartclash opened this issue Jun 15, 2020 · 9 comments · May be fixed by #7
Assignees
Labels
enhancement New feature or request
Projects

Comments

@smartclash
Copy link
Member

smartclash commented Jun 15, 2020

Summary

Type definitions help ensure your code is correct, but it’s also very useful to ensure your types are correct, especially if you ship types with your library. Ensuring that you get type errors where you expect is also useful, so your types don’t regress in functionality by accident. Being able to test your types next to your logic, with much the same API, will make it easier for people to maintain high quality type definitions.
This will help APIs injected into a test by Jest are well typed.

Test Plan

  • This can be tackled by making a custom runner that will just extend SamVerschueren/tsd inside.
  • tsd essentially runs the typescript compiler and injects assertions, which can be added in a custom runner which will run part of Jest's test suite
  • The issue is targeted towards "write tests for Jest's own types" rather than "create a typings test runner"
  • Assert type tests for expect and different jest objects like jest.mock, etc
  • Assertions that invalid things are reported as type errors would be great.

Todos

  • Basic Scaffolding
  • Integrate TSD
    • There are techniques like const a: import("jest").Expect which would allow types to be passed around internally without too much churn
  • Write tests for this runner
  • Update the documentation (and CHANGELOG.md)

References

@smartclash smartclash created this issue from a note in MLH x Jest (To do) Jun 15, 2020
@smartclash
Copy link
Member Author

Could probably draw inspiration from jest-runner-prettier

@smartclash smartclash self-assigned this Jun 15, 2020
@smartclash smartclash added the enhancement New feature or request label Jun 15, 2020
@smartclash smartclash moved this from To do to In progress in MLH x Jest Jun 17, 2020
@kunal-kushwaha kunal-kushwaha moved this from In progress to To do in MLH x Jest Jun 17, 2020
@smartclash smartclash moved this from To do to In progress in MLH x Jest Jun 17, 2020
@kunal-kushwaha kunal-kushwaha changed the title Integrate a runner to test TS Typings. Integrate a runner and reporter for testing types Jun 19, 2020
@kunal-kushwaha kunal-kushwaha self-assigned this Jun 19, 2020
@kunal-kushwaha
Copy link
Member

kunal-kushwaha commented Jun 19, 2020

@sauravhiremath @jevakallio @smartclash I have updated the Summary, Todos and Test Plan. Feedback required 👍

@smartclash
Copy link
Member Author

Since this issue is more of having to make a custom runner, we'll be making this as a separate project. Integrating it inside Jest itself could be a bad idea.

You can follow the development of this runner at https://github.com/MLH-Fellowship/jest-runner-tsd/

@kunal-kushwaha
Copy link
Member

I agree

@SimenB
Copy link
Collaborator

SimenB commented Jun 23, 2020

Sorry I never got back to this - the plan looks great!

@smartclash
Copy link
Member Author

The underlying library (TSD) that we are planning to import needs some stuffs to be fixed. So, a fork has been made at https://github.com/MLH-Fellowship/tsd. They'll be fixed and we will be opening a PR to the origin. After it is merged it'll be used in custom runner that we are making.

@smartclash
Copy link
Member Author

smartclash commented Aug 4, 2020

Final work plan:

We'll be having a separate config file for jest, something like jest.config.types.js which will use the custom runner we are making (jest-runner-tsd).

We'll also be adding a script inside package.json so that we can test types by running yarn test-types which would basically run jest with the jest.config.types.js config.

About where to place the type definition test files, I think it would be great to place them under __tests__ folder of each package and name the file as types.test.ts.

Or we can have a new folder inside __tests__ something like types and place multiple test files inside the types folder.

Let me know which one is the better approach or if you have something better.

No matter which approach, we have to configure testRegex option to make it correctly find the test files.

References:

@SimenB
Copy link
Collaborator

SimenB commented Aug 14, 2020

If the PRs take time landing in upstream tsd I vote for publishing a fork and using that in the runner to unblock work in landing this in Jest. Should be simple enough to switch back to mainline once tsd is updated 🙂

MLH x Jest automation moved this from In progress to Done Aug 20, 2020
@github-actions
Copy link

This issue 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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 14, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request
Projects
MLH x Jest
  
Done
Development

Successfully merging a pull request may close this issue.

3 participants