Autofix

Author: afontcu

docs/cypress-testing-library/intro.md

@@ -22,7 +22,7 @@ Add this line to your project's `cypress/support/commands.js`:
 import '@testing-library/cypress/add-commands';
 ```
 
-## With typescript
+## With TypeScript
 
 Typings are defined under @testing-library/cypress/typings, and should be added
 as follows in tsconfig.json:

docs/dom-testing-library/api-helpers.md

@@ -86,10 +86,10 @@ and add it here!
 getNodeText(node: HTMLElement)
 ```
 
-Returns the complete text content of a html element, removing any extra
+Returns the complete text content of a HTML element, removing any extra
 whitespace. The intention is to treat text in nodes exactly as how it is
 perceived by users in a browser, where any extra whitespace within words in the
-html code is not meaningful when the text is rendered.
+HTML code is not meaningful when the text is rendered.
 
 ```javascript
 // <div>

docs/dom-testing-library/faq.md

@@ -42,12 +42,12 @@ with `data-testid`s (which is not bad anyway).
 
 Definitely not. That said, a common reason people don't like the `data-testid`
 attribute is they're concerned about shipping that to production. I'd suggest
-that you probably want some simple E2E tests that run in production on occasion
-to make certain that things are working smoothly. In that case the `data-testid`
-attributes will be very useful. Even if you don't run these in production, you
-may want to run some E2E tests that run on the same code you're about to ship to
-production. In that case, the `data-testid` attributes will be valuable there as
-well.
+that you probably want some simple end-to-end tests that run in production on
+occasion to make certain that things are working smoothly. In that case the
+`data-testid` attributes will be very useful. Even if you don't run these in
+production, you may want to run some end-to-end tests that run on the same code
+you're about to ship to production. In that case, the `data-testid` attributes
+will be valuable there as well.
 
 All that said, if you really don't want to ship `data-testid` attributes, then
 you can use

docs/marko-testing-library/intro.md

@@ -42,7 +42,7 @@ will work with actual DOM nodes. The utilities this library provides facilitate
 querying the DOM in the same way the user would. Finding for elements by their
 label text (just like a user would), finding links and buttons from their text
 (like a user would). It contains a small targeted API and can get out of your
-way if absolutely needed with some built in escape hatches.
+way if absolutely needed with some built-in escape hatches.
 
 This library encourages your applications to be more accessible and allows you
 to get your tests closer to using your components the way a user will, which

docs/marko-testing-library/setup.md

@@ -44,7 +44,7 @@ module.exports = {
 For testing components rendered server side we can omit the `browser` option,
 however ideally you should also set the
 [`testEnvironment option`](https://jestjs.io/docs/en/configuration#testenvironment-string)
-to `node` which will disable loading JSDOM globally.
+to `node` which will disable loading jsdom globally.
 
 **jest.config.js**
 

docs/native-testing-library/intro.md

@@ -45,7 +45,7 @@ like `React Testing Library` are thin layers over `DOM Testing Library`, this
 library needed to have its own base implementation as well as a user-facing API.
 This library uses the
 [react-test-renderer](https://reactjs.org/docs/test-renderer.html), whereas
-`DOM Testing Library` uses ReactDOM and JSDOM. The main philosophy is that you
+`DOM Testing Library` uses ReactDOM and jsdom. The main philosophy is that you
 should find elements that are on the "screen" the way users would. This approach
 is meant to give you confidence that your app is working as a cohesive unit.
 Just like the `DOM Testing Library`, `Native Testing Library`'s primary guiding

docs/react-testing-library/cheatsheet.md

@@ -106,7 +106,7 @@ See [Which query should I use?](guide-which-query.md)
 
 ## Async
 
-See [dom-testing-library Async API](dom-testing-library/api-async.md)
+See [DOM Testing Library Async API](dom-testing-library/api-async.md)
 
 - **wait** (Promise) retry the function within until it stops throwing or times
  out

docs/react-testing-library/setup.md

@@ -257,7 +257,7 @@ module.exports = {
 }
 ```
 
-_Typescript config needs to be updated as follow:_
+_TypeScript config needs to be updated as follow:_
 
 ```diff
 // tsconfig.json

docs/svelte-testing-library/intro.md

@@ -10,7 +10,7 @@ title: Svelte Testing Library
 npm install --save-dev @testing-library/svelte
 ```
 
-- [svelte-testing-library on GitHub][gh]
+- [Svelte Testing Library on GitHub][gh]
 
 ## Usage
 

docs/testcafe-testing-library/intro.md

@@ -11,12 +11,12 @@ testing.
 npm install --save-dev testcafe @testing-library/testcafe
 ```
 
-- [testcafe-testing-library on GitHub][gh]
+- [TestCafe Testing Library on GitHub][gh]
 
 ## Usage
 
 `testcafe-testing-library` provides custom Selectors allowing you to query the
-dom.
+DOM.
 
 Add `testcafe-testing-library` to your test fixture's `beforeEach` hook: