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
Unless the intended purpose of the above is to test two possibly different types, the function parameters should be unambiguous and of the same type.
typetoBe=<Type>(a: Type,b: Type)=>boolean
Examples:
declarefunctionf(a: unknown,b: unknown): booleandeclarefunctiong<Type>(a: Type,b: Type): booleanf(1,'1')// compiler does not complaing(1,'1')// compiler does complain
toBeDefined
typetoBeDefined=(a: any)=>boolean
This just needs a small update if an only if getting rid of the 'no implicit any' error is found to be necessary.
typetoBeDefined=<Type>(a: Type)=>boolean
toBeFalse
typetoBeFalse=(a: any)=>boolean
This just needs a small update if an only if getting rid of the 'no implicit any' error is found to be necessary.
This one is a bit difficult due to duck typing. That is that if two class A and B have the same interface, then even with restrictive type checking an instance of A can be passed as argument against the constructor of B and vice versa. The runtime will still catch this due to the use of instaceof. In the proposed new typing the arguments are spread and of the type never. Never is okay here because we do not need to know the arguments and covers different arguments along with no arguments.
// the most restrictive: ensures from a static perspective that instance is of the constructor. // This is not perfect due to duck typing,typetoBeInstanceOf=<Type,Constructorextends{new(...args : never[]): Type}>(constructor: Constructor,instance: InstanceType<Constructor>): boolean
classA{size: numberconstructor(initialSize: number){this.size=initialSize;}}classB{size: stringconstructor(initialSize: string){this.size=initialSize;}}classC{size: numberconstructor(){this.size=0}}classD{size: numbershape: stringconstructor(size: number,shape: string){this.size=sizethis.shape=shape}}consta=newA(1)constb=newB('1')constc=newC()constd=newD(1,'l')console.log(toBeInstanceOf(A,a))// base case with argumentsconsole.log(toBeInstanceOf(A,b))// this is caught as A and B interfaces do not have the same shapeconsole.log(toBeInstanceOf(A,c))// duck typing does not catch this, both A and C have the same shapeconsole.log(toBeInstanceOf(C,c))// no args worksconsole.log(toBeInstanceOf(D,d))// more than one arg works// duck typing does not catch this as D has { size: number } in its interface // and { size: number } is the interface of Aconsole.log(toBeInstanceOf(A,d))// This does not work as A does not have the same shape as D// A is missing { shape: string }console.log(toBeInstanceOf(D,a))
toBeNan
typetoBeNaN=(a: string|number)=>boolean
Only a small update needed if there is a desire to keep function signatures uniform.
This function can be a bit more specific, and with using function overloads you can ensure that it works for both object types with heterogeneous keys/values, along with heterogeneous arrays.
One thing to take note of is the current implementation does not check for deep equality, and it may be worth while creating a toBeDeepEqual matcher
toHaveLength
typetoHaveLength=(a: unknown,b: number)=>boolean
This could be a bit more specific. One signature could be anything that has the length property, allowing you to test anything with length, not just arrays. And another signature for any type of object. Does this need to also handle length of numbers?
Matchers
toBe
Unless the intended purpose of the above is to test two possibly different types, the function parameters should be unambiguous and of the same type.
Examples:
toBeDefined
This just needs a small update if an only if getting rid of the 'no implicit any' error is found to be necessary.
toBeFalse
This just needs a small update if an only if getting rid of the 'no implicit any' error is found to be necessary.
toBeInstanceOf
This one is a bit difficult due to duck typing. That is that if two class A and B have the same interface, then even with restrictive type checking an instance of A can be passed as argument against the constructor of B and vice versa. The runtime will still catch this due to the use of
instaceof
. In the proposed new typing the arguments are spread and of the type never. Never is okay here because we do not need to know the arguments and covers different arguments along with no arguments.Implementation
Examples:
toBeNan
Only a small update needed if there is a desire to keep function signatures uniform.
toBeNull
This just needs a small update if an only if getting rid of the 'no implicit any' error is found to be necessary.
toBeTrue
This just needs a small update if an only if getting rid of the 'no implicit any' error is found to be necessary.
toBeTypeOf
This just needs a small update to ensure that both arguments are statically the same type. It may still catch errors in the runtime.
toBeUndefined
This just needs a small update if an only if getting rid of the 'no implicit any' error is found to be necessary.
toContain
This function can be a bit more specific, and with using function overloads you can ensure that it works for both object types with heterogeneous keys/values, along with heterogeneous arrays.
Implementation:
Examples:
toEqual
This just needs a small update if an only if getting rid of the 'no implicit any' error is found to be necessary.
One thing to take note of is the current implementation does not check for deep equality, and it may be worth while creating a
toBeDeepEqual
matchertoHaveLength
This could be a bit more specific. One signature could be anything that has the length property, allowing you to test anything with length, not just arrays. And another signature for any type of object. Does this need to also handle length of numbers?
Implementation
Examples
toStrictlyEqual
This just needs a small update to ensure that both arguments are statically the same type. It may still catch errors in the runtime.
toThrow
This one is a little difficult to figure out and determining the spec would make it much easier to refactor. Let's circle back to it.
The text was updated successfully, but these errors were encountered: