test: create utility function to infer rule types

[marcalexiei]

During #174 and #175 I noticed that in test files rule options types are not inferred inside test functions.

To avoid this problem I added createRuleTestCaseFunction that returns a function that can be used to generate both valid and invalid cases.

This function accept only 1 type parameter which is used to infer rule Options and MessageIds which are not exported from the rule source file.

Pros

The immediate advantage is that now types are properly inferred from the rule declaration and a type error is reported if the rule Options type doesn't match them:

Intellisense on rule options screenshot

---

Additionally also rule MessageIds type can be inferred and provided as autocomplete suggestions:

Intellisense on rule message ids screenshot

Cons

The only problem is that Invalid test case errors property now use the messageId and data structure rather than simple strings: you can see the impact of these changes on the two rules test files changed in this PR.

I'm willing to convert all test to this pattern but I understand that this will also increase maintenance efforts while pulling changes from the upstream repository, so no problem if you don't want to proceed with this change 😉.

[changeset-bot]

⚠️ No Changeset found

Latest commit: b8d14f3

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 96.09%. Comparing base (e01dce0) to head (65a8118).

Additional details and impacted files

@@           Coverage Diff           @@
##           master     #176   +/-   ##
=======================================
  Coverage   96.09%   96.09%           
=======================================
  Files         101      101           
  Lines        4688     4692    +4     
  Branches     1613     1613           
=======================================
+ Hits         4505     4509    +4     
  Misses        177      177           
  Partials        6        6           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[marcalexiei]

After what discussed in typescript-eslint/typescript-eslint#10321 I would consider to provide plain objects to the RuleTester#run method:
test helper function is used to provide a default set of languagesOptions to each test case but I think that it can be done once when creating a RuleTester instance:

• test/utils could export a TEST_RULE_DEFAULT_LANGUAGE_OPTIONS or a getTestRuleDefaultLanguageOptions function that returns the very same object, which then is passed when creating RuleTester instance (if required)
• test function will be deprecated
• createRuleTestCaseFunction can be removed since the plain objects provided to RuleTester#run are already type-checked.

What do you think?

[SukkaW]

After what discussed in typescript-eslint/typescript-eslint#10321 I would consider to provide plain objects to the RuleTester#run method: test helper function is used to provide a default set of languagesOptions to each test case but I think that it can be done once when creating a RuleTester instance:

• test/utils could export a TEST_RULE_DEFAULT_LANGUAGE_OPTIONS or a getTestRuleDefaultLanguageOptions function that returns the very same object, which then is passed when creating RuleTester instance (if required)
• test function will be deprecated
• createRuleTestCaseFunction can be removed since the plain objects provided to RuleTester#run are already type-checked.

What do you think?

There are many variations of lanaguageOptions (at least 5?) passed to the test function among all those tests. We can't create a rule tester instance for each lanaguageOptions. IMHO let's stick with one rule tester instance here.

RuleTester#run is already type-checked, but if you can further improve test DX, feel free to go ahead!

[marcalexiei]

Ok, I'll update the two rules I already edited in this PR and then if you like the result we can move on!

[SukkaW]

LGTM!