-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Following documentation, regarding a tip about @ts-expect-error
, I cannot make tests behave as I would expect from the documentation
#5604
Comments
It might be that "tip" is outdated or simply wrong. Currently, I'm not sure what's the best way to do this currently other than running vitest twice. |
Note that Solution: the old good Separation of Concerns principle. Use JavaScript testing tool to test runtime behaviour. Use specialised type testing tool to test types. There are at least two type testing tools which offer a type error assertion instead of |
Could you please refer to these tools for clarity? With Vitest, I gravitated towards A minimal example of my use case, for context: // to test against
function argFail<const T extends [1, never, 3]>(...arg: T) {}
//#region readable
argFail(
1,
// @ts-expect-error invalid
2,
3,
);
//#endregion
//#region messy, but intended way of testing, with expect-type?
type argFail_params = Parameters<typeof argFail>;
const arg = [1, 2, 3] as const;
expectTypeOf(arg[1]).not.toMatchTypeOf<argFail_params[1]>();
//#endregion In a realistic scenario, Much more practical to just test a natural invocation of |
Sure. I had in mind:
To be honest, a type error assertion is not an ideal solution too. It would be the best to have This matcher is complex. The most interesting part is to resolve argument types of generic functions. Programatically this is possible and I have a working prototype. That means that eventually |
Cheers, as I suspected there's not really a canonical way to go about this, and so I will stick to I will leave it to the maintainers to decide about the tip in the docs, but if I may provide input, it did waste me some time to realize that it's not working as intended, and at least some warning around it would be a welcome addition while the upstream issues are resolved. |
Describe the bug
There's a "tip" over at https://vitest.dev/guide/testing-types.html#run-typechecking, saying:
After adjusting the
test.include
array invitest.config.ts
, I cannot make all my tests work.There are 3 test files to present the issue:
ReferenceError
There are 2 npm scripts
npm run test
--typecheck
, after reading the docsnpm run test-no-typecheck
--typecheck
flag, there's also this scriptUpon running
npm run test
, the results are:Upon running
npm run test-no-typecheck
, the results are:What I would expect, is for at least one of the npm scripts to result in every test failing.
Reproduction
https://github.com/danwithabox/issue_vitest_vitest-dev_5604
System Info
Used Package Manager
npm
Validations
The text was updated successfully, but these errors were encountered: