Note the string[] return type of getNames() function. It's literally always "defined" so .toBeDefined() does not make any sense here, but neither TS nor ESLint complain about it, giving developers a false feeling of good tests.
Actual result: no errors, tests obviously pass while they make no sense.
Expected result: linter error saying Type of "app" variable is "TestingModule", it can not be undefined. It is useless to check it with .toBeDefined() matcher.
Example:
Do you think eslint-plugin-jest is the right place to have a new rule, checking already known types of variables and checking matchers, disallowing useless usage?
Currently, the following code doesn't produce any errors neither from TS, nor from
@typescript/eslint
andeslint-plugin-jest
:Note the
string[]
return type ofgetNames()
function. It's literally always "defined" so.toBeDefined()
does not make any sense here, but neither TS nor ESLint complain about it, giving developers a false feeling of good tests.Actual result: no errors, tests obviously pass while they make no sense.
Expected result: linter error saying
Type of "app" variable is "TestingModule", it can not be undefined. It is useless to check it with .toBeDefined() matcher.
Example:
Do you think
eslint-plugin-jest
is the right place to have a new rule, checking already known types of variables and checking matchers, disallowing useless usage?Some expiration for implementation can be found in
typescript-eslint
'sno-unnecessary-type-assertion