docs: including testing-library prefix in all rules

Author: Belco90

docs/rules/await-async-query.md

@@ -1,4 +1,4 @@
-# Enforce promises from async queries to be handled (await-async-query)
+# Enforce promises from async queries to be handled (`testing-library/await-async-query`)
 
 Ensure that promises returned by async queries are handled properly.
 

docs/rules/await-async-utils.md

@@ -1,4 +1,4 @@
-# Enforce promises from async utils to be handled (await-async-utils)
+# Enforce promises from async utils to be handled (`testing-library/await-async-utils`)
 
 Ensure that promises returned by async utils are handled properly.
 

docs/rules/await-fire-event.md

@@ -1,4 +1,4 @@
-# Enforce promises from fire event methods to be handled (await-fire-event)
+# Enforce promises from fire event methods to be handled (`testing-library/await-fire-event`)
 
 Ensure that promises returned by `fireEvent` methods are handled
 properly.

docs/rules/consistent-data-testid.md

@@ -1,4 +1,4 @@
-# Enforces consistent naming for the data-testid attribute (consistent-data-testid)
+# Enforces consistent naming for the data-testid attribute (`testing-library/consistent-data-testid`)
 
 Ensure `data-testid` values match a provided regex. This rule is un-opinionated, and requires configuration.
 

docs/rules/no-await-sync-events.md

@@ -1,4 +1,4 @@
-# Disallow unnecessary `await` for sync events (no-await-sync-events)
+# Disallow unnecessary `await` for sync events (`testing-library/no-await-sync-events`)
 
 Ensure that sync simulated events are not awaited unnecessarily.
 

docs/rules/no-await-sync-query.md

@@ -1,4 +1,4 @@
-# Disallow unnecessary `await` for sync queries (no-await-sync-query)
+# Disallow unnecessary `await` for sync queries (`testing-library/no-await-sync-query`)
 
 Ensure that sync queries are not awaited unnecessarily.
 

docs/rules/no-container.md

@@ -1,4 +1,4 @@
-# Disallow the use of `container` methods (no-container)
+# Disallow the use of `container` methods (`testing-library/no-container`)
 
 By using `container` methods like `.querySelector` you may lose a lot of the confidence that the user can really interact with your UI. Also, the test becomes harder to read, and it will break more frequently.
 

docs/rules/no-debug.md

@@ -1,4 +1,4 @@
-# Disallow the use of `debug` (no-debug)
+# Disallow the use of `debug` (`testing-library/no-debug`)
 
 Just like `console.log` statements pollutes the browser's output, debug statements also pollutes the tests if one of your teammates forgot to remove it. `debug` statements should be used when you actually want to debug your tests but should not be pushed to the codebase.
 

docs/rules/no-dom-import.md

@@ -1,4 +1,4 @@
-# Disallow importing from DOM Testing Library
+# Disallow importing from DOM Testing Library (`testing-library/no-dom-import`)
 
 Ensure that there are no direct imports from `@testing-library/dom` or
 `dom-testing-library` when using some testing library framework
@@ -7,18 +7,18 @@ wrapper.
 ## Rule Details
 
 Testing Library framework wrappers as React Testing Library already
-re-exports everything from DOM Testing Library so you always have to
-import DOM Testing Library utils from corresponding framework wrapper
+re-exports everything from DOM Testing Library, so you always have to
+import Testing Library utils from corresponding framework wrapper
 module to:
 
 - use proper extended version of some of those methods containing
   additional functionality related to specific framework (e.g.
   `fireEvent` util)
 - avoid importing from extraneous dependencies (similar to
-  eslint-plugin-import)
+  `eslint-plugin-import`)
 
 This rule aims to prevent users from import anything directly from
-`@testing-library/dom` (or `dom-testing-library`) and it's useful for
+`@testing-library/dom`, which is useful for
 new starters or when IDEs autoimport from wrong module.
 
 Examples of **incorrect** code for this rule:

docs/rules/no-manual-cleanup.md

@@ -1,4 +1,4 @@
-# Disallow the use of `cleanup` (no-manual-cleanup)
+# Disallow the use of `cleanup` (`testing-library/no-manual-cleanup`)
 
 `cleanup` is performed automatically if the testing framework you're using supports the `afterEach` global (like mocha, Jest, and Jasmine). In this case, it's unnecessary to do manual cleanups after each test unless you skip the auto-cleanup with environment variables such as `RTL_SKIP_AUTO_CLEANUP` for React.
 

docs/rules/no-node-access.md

@@ -1,4 +1,4 @@
-# Disallow direct Node access (no-node-access)
+# Disallow direct Node access (`testing-library/no-node-access`)
 
 The Testing Library already provides methods for querying DOM elements.
 

docs/rules/no-promise-in-fire-event.md

@@ -1,4 +1,4 @@
-# Disallow the use of promises passed to a `fireEvent` method (no-promise-in-fire-event)
+# Disallow the use of promises passed to a `fireEvent` method (`testing-library/no-promise-in-fire-event`)
 
 Methods from `fireEvent` expect to receive a DOM element. Passing a promise will end up in an error, so it must be prevented.
 

docs/rules/no-render-in-setup.md

@@ -1,4 +1,4 @@
-# Disallow the use of `render` in setup functions (no-render-in-setup)
+# Disallow the use of `render` in setup functions (`testing-library/no-render-in-setup`)
 
 ## Rule Details
 

docs/rules/no-wait-for-empty-callback.md

@@ -1,4 +1,4 @@
-# Empty callbacks inside `waitFor` and `waitForElementToBeRemoved` are not preferred (no-wait-for-empty-callback)
+# Empty callbacks inside `waitFor` and `waitForElementToBeRemoved` are not preferred (`testing-library/no-wait-for-empty-callback`)
 
 ## Rule Details
 

docs/rules/no-wait-for-multiple-assertions.md

@@ -1,4 +1,4 @@
-# Multiple assertions inside `waitFor` are not preferred (no-wait-for-multiple-assertions)
+# Disallow the use of multiple expect inside `waitFor` (`testing-library/no-wait-for-multiple-assertions`)
 
 ## Rule Details
 

docs/rules/no-wait-for-side-effects.md

@@ -1,4 +1,4 @@
-# Side effects inside `waitFor` are not preferred (no-wait-for-side-effects)
+# Disallow the use of side effects inside `waitFor` (`testing-library/no-wait-for-side-effects`)
 
 ## Rule Details
 

docs/rules/no-wait-for-snapshot.md

@@ -1,13 +1,13 @@
-# Ensures no snapshot is generated inside of a `wait` call' (no-wait-for-snapshot)
+# Ensures no snapshot is generated inside a `waitFor` call (`testing-library/no-wait-for-snapshot`)
 
 Ensure that no calls to `toMatchSnapshot` or `toMatchInlineSnapshot` are made from within a `waitFor` method (or any of the other async utility methods).
 
 ## Rule Details
 
 The `waitFor()` method runs in a timer loop. So it'll retry every n amount of time.
-If a snapshot is generated inside the wait condition, jest will generate one snapshot per loop.
+If a snapshot is generated inside the wait condition, jest will generate one snapshot per each loop.
 
-The problem then is the amount of loop ran until the condition is met will vary between different computers (or CI machines). This leads to tests that will regenerate a lot of snapshots until the condition is matched when devs run those tests locally updating the snapshots; e.g devs cannot run `jest -u` locally or it'll generate a lot of invalid snapshots who'll fail during CI.
+The problem then is the amount of loop ran until the condition is met will vary between different computers (or CI machines). This leads to tests that will regenerate a lot of snapshots until the condition is matched when devs run those tests locally updating the snapshots; e.g. devs cannot run `jest -u` locally, or it'll generate a lot of invalid snapshots which will fail during CI.
 
 Note that this lint rule prevents from generating a snapshot from within any of the [async utility methods](https://testing-library.com/docs/dom-testing-library/api-async).
 

docs/rules/prefer-explicit-assert.md

@@ -1,4 +1,4 @@
-# Suggest using explicit assertions rather than just `getBy*` queries (prefer-explicit-assert)
+# Suggest using explicit assertions rather than just `getBy*` queries (`testing-library/prefer-explicit-assert`)
 
 Testing Library `getBy*` queries throw an error if the element is not
 found. Some users like this behavior to use the query itself as an

docs/rules/prefer-find-by.md

@@ -1,11 +1,11 @@
-# Suggest using `findBy*` methods instead of the `waitFor` + `getBy` queries (prefer-find-by)
+# Suggest using `findBy*` methods instead of the `waitFor` + `getBy` queries (`testing-library/prefer-find-by`)
 
 findBy* queries are a simple combination of getBy* queries and waitFor. The findBy\* queries accept the waitFor options as the last argument. (i.e. screen.findByText('text', queryOptions, waitForOptions))
 
 ## Rule details
 
-This rule aims to use `findBy*` or `findAllBy*` queries to wait for elements, rather than using `waitFor`, or the deprecated methods `waitForElement` and `wait`.  
-This rules analyzes those cases where `waitFor` is used with just one query method, in the form of an arrow function with only one statement (that is, without a block of statements). Given the callback could be more complex, this rule does not consider function callbacks or arrow functions with blocks of code
+This rule aims to use `findBy*` or `findAllBy*` queries to wait for elements, rather than using `waitFor`, or the deprecated methods `waitForElement` and `wait`.
+This rule analyzes those cases where `waitFor` is used with just one query method, in the form of an arrow function with only one statement (that is, without a block of statements). Given the callback could be more complex, this rule does not consider function callbacks or arrow functions with blocks of code
 
 Examples of **incorrect** code for this rule
 

docs/rules/prefer-presence-queries.md

@@ -1,4 +1,4 @@
-# Enforce specific queries when checking element is present or not (prefer-presence-queries)
+# Enforce specific queries when checking element is present or not (`testing-library/prefer-presence-queries`)
 
 The (DOM) Testing Library allows to query DOM elements using different types of queries such as `get*` and `query*`. Using `get*` throws an error in case the element is not found, while `query*` returns null instead of throwing (or empty array for `queryAllBy*` ones). These differences are useful in some situations:
 

docs/rules/prefer-screen-queries.md

@@ -1,4 +1,4 @@
-# Suggest using screen while using queries (prefer-screen-queries)
+# Suggest using `screen` while using queries (`testing-library/prefer-screen-queries`)
 
 ## Rule Details
 

docs/rules/prefer-user-event.md

@@ -1,4 +1,4 @@
-# Use [userEvent](https://github.com/testing-library/user-event) over using `fireEvent` for user interactions (prefer-user-event)
+# Suggest using `userEvent` library instead of `fireEvent` for simulating user interaction (`testing-library/prefer-user-event`)
 
 From
 [testing-library/dom-testing-library#107](https://github.com/testing-library/dom-testing-library/issues/107):
@@ -97,8 +97,8 @@ When you don't want to use `userEvent`, such as if a legacy codebase is still us
 
 ## Further Reading
 
-- [userEvent repository](https://github.com/testing-library/user-event)
-- [userEvent in the react-testing-library docs](https://testing-library.com/docs/ecosystem-user-event)
+- [`user-event` repository](https://github.com/testing-library/user-event)
+- [`userEvent` in the Testing Library docs](https://testing-library.com/docs/ecosystem-user-event)
 
 ## Appendix
 

docs/rules/prefer-wait-for.md

@@ -1,4 +1,4 @@
-# Use `waitFor` instead of deprecated wait methods (prefer-wait-for)
+# Use `waitFor` instead of deprecated wait methods (`testing-library/prefer-wait-for`)
 
 `dom-testing-library` v7 released a new async util called `waitFor` which satisfies the use cases of `wait`, `waitForElement`, and `waitForDomChange` making them deprecated.
 

docs/rules/render-result-naming-convention.md

@@ -1,4 +1,4 @@
-# Enforce a valid naming for return value from `render` (render-result-naming-convention)
+# Enforce a valid naming for return value from `render` (`testing-library/render-result-naming-convention`)
 
 > The name `wrapper` is old cruft from `enzyme` and we don't need that here. The return value from `render` is not "wrapping" anything. It's simply a collection of utilities that you should actually not often need anyway.