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

.toBeCallableWith() does not work with generic functions or overloads #50

Closed
mrazauskas opened this issue Dec 8, 2023 · 2 comments
Closed

Comments

@mrazauskas
Copy link
Contributor

If a generic function is declared like this:

export declare function foo<T>(x: T, y: T): T;

The .toBeCallableWith() matcher fails:

expectTypeOf(bar).toBeCallableWith(123, "123"); // no error reported

foo(123, "123");
         ~~~~~ Argument of type '"123"' is not assignable to parameter of type '123'.

Testing an overloaded function:

export declare const foo: {
  (x: string, y: string): string;
  (x: number, y: number): number;
};

Does not work either:

expectTypeOf(foo).toBeCallableWith("abc", "efg");
                                   ~~~~~ Argument of type 'string' is not assignable to parameter of type 'number'.
expectTypeOf(foo).toBeCallableWith(123, 456);

foo("abc", "efg");  // but all is good here
foo(123, 456);

Hm.. If a simple foo() does the job (and does it better!), what is the purpose of .toBeCallableWith()? I mean, .toEqualTypeOf() works perfectly in both of the cases I mentioned above:

expectTypeOf(foo("abc", "efg")).toEqualTypeOf<string>();
expectTypeOf(foo(123, 456)).toEqualTypeOf<number>();

.not.toBeCallableWith() could handle a check which .toEqualTypeOf() cannot and would be more useful than // @ts-expect-error. Unfortunately it is not implemented at the moment.

@mmkal
Copy link
Owner

mmkal commented Jan 17, 2024

Hm.. If a simple foo() does the job (and does it better!), what is the purpose of .toBeCallableWith()? I mean, .toEqualTypeOf() works perfectly in both of the cases I mentioned above:

Yeah, I sometimes regret adding toBeCallableWith for this reason. The advantages of it:

  1. It's more explicit - it says "I am testing that this function accepts these parameters" rather than expectTypeOf(foo(...)).toEqualTypeOf<...>() which looks more like "I am testing that this function has this return type".
  2. It doesn't involve actually calling the function, which may have side-effects.

But outside of those, you're probably better off with foo(...) in this case.

@mrazauskas
Copy link
Contributor Author

Thanks for explanation.

I’m leaving the issue open in case you would like to document the limitation with overloaded and generic functions. Feel free to close, if that does not look significant.

@mmkal mmkal closed this as completed in 2ab099c Mar 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants