Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork2.8k
Description
Before You File a Documentation Request Please Confirm You Have Done The Following...
- I have looked for existingopen or closed documentation requests that match my proposal.
- I haveread the FAQ and my problem is not listed.
Suggested Changes
I think one of, if not the most, common requests for changes I put in PR reviews is uncovered test lines in lint rules. Folks oftentimes don't test cases the AST is forcing them to write edge case code for. Or the reverse: they use type assertions to get around cases the AST types are trying to force them to handle.
I very often end up posting some comment like:
Looks like there are some gaps in unit test coverage. For each gap in coverage, at least one of the following is probably true:
- The code is reachable, so a unit test should exercise it
- The code can be refactored to not include that case
- This is a difficult-to-represent edge case in types and a type assertion is warranted
I'd love to have an explainer resource that explains what each of those mean, with an example. That'd save me a lot of typing - and would help promote understanding of how to work with the AST properly.
Proposal: let's make this into a blog post?
Affected URL(s)
Maybe:https://typescript-eslint.io/blog/tips-for-increasing-lint-rule-test-coverage
?
Additional Info
I have a general blog post on this type of request drafted here:JoshuaKGoldberg/dot-com#324.https://github.com/JoshuaKGoldberg/dot-com/blob/d7d2f348ecf38fb2e3012fb06c85db16f1267cdf/src/content/blog/so-youve-got-a-gap-in-code-coverage-for-a-lint-rule/index.mdx?plain=1 is a partially-done version of it specific to lint rules. I'd started writing that, then realized I wanted to be more general to JS/TS in my own blog.