You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Currently when using matchers like toStrictEqual (and many others), the type of the argument is unknown, which can potentially make it (slightly) slower to make tests correct and ensure type safety. Compared to using assertStrictEquals from @std/assert, it does allow passing a generic.
Allowing us to pass a generic can also help ensure we don't make the same typo if, for example, we have to do a typescript assertion (like if we are using .reduce for an object with inferred keys with Object.entries).
E.g.
import{expect}from'jsr:@std/expect';interfaceBar={ ... }interfaceFoo{abc: string;def: string;}constbarToFoo=(bar: Bar): Foo=>({ ... });Deno.test('given bar, it returns foo',()=>{constvalue=barToFoo(bar);expect(value).toStrictEqual({acb: 'foo',// this would be allowed because the type isn't enforceddef: 'foo',});});
It would be great if the type of toStrictEqual (and likely other matchers) could accept an optional generic so that we can get IDE completion and type checking for the values we enter, without having to make a separate variable.
E.g.:
Deno.test('given bar, it returns foo',()=>{constvalue=barToFoo(bar);expect(value).toStrictEqual<Foo>({acb: 'foo',// typescript would tell us off here because `acb` isn't a property in `Foo`def: 'foo',});});
Describe alternatives you've considered
(Not a big deal) Creating separate variables for the values used in assertions, e.g.:
Deno.test('given bar, it returns foo',()=>{constvalue=barToFoo(bar);constexpected: Foo={acb: 'foo',// typescript would tell us off here because `acb` isn't a property in `Foo`def: 'foo',};expect(value).toStrictEqual(expected);});
I would be willing to make a PR for this if accepted :)
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
Currently when using matchers like
toStrictEqual
(and many others), the type of the argument isunknown
, which can potentially make it (slightly) slower to make tests correct and ensure type safety. Compared to usingassertStrictEquals
from@std/assert
, it does allow passing a generic.Allowing us to pass a generic can also help ensure we don't make the same typo if, for example, we have to do a typescript assertion (like if we are using
.reduce
for an object with inferred keys withObject.entries
).E.g.
@std/expect#toStrictEqual
source@std/assert#assertStrictEquals
source@types/jest#toStrictEqual
sourceDescribe the solution you'd like
It would be great if the type of
toStrictEqual
(and likely other matchers) could accept an optional generic so that we can get IDE completion and type checking for the values we enter, without having to make a separate variable.E.g.:
Describe alternatives you've considered
(Not a big deal) Creating separate variables for the values used in assertions, e.g.:
I would be willing to make a PR for this if accepted :)
The text was updated successfully, but these errors were encountered: