docs: correct grammatical & spelling errors

Author: G-Rath

docs/rules/consistent-test-it.md

@@ -71,7 +71,7 @@ describe('foo', function() {
 
 ### Default configuration
 
-The default configuration forces top level test to use `test` and all tests
+The default configuration forces all top-level tests to use `test` and all tests
 nested within `describe` to use `it`.
 
 ```js

docs/rules/no-export.md

@@ -1,14 +1,13 @@
 # Disallow using `exports` in files containing tests (`no-export`)
 
-Prevents exports from test files. If a file has at least 1 test in it, then this
-rule will prevent exports.
+Prevents using `exports` if a file has one or more tests in it.
 
 ## Rule Details
 
 This rule aims to eliminate duplicate runs of tests by exporting things from
 test files. If you import from a test file, then all the tests in that file will
 be run in each imported instance, so bottom line, don't export from a test, but
-instead move helper functions into a seperate file when they need to be shared
+instead move helper functions into a separate file when they need to be shared
 across tests.
 
 Examples of **incorrect** code for this rule:

docs/rules/prefer-inline-snapshots.md

@@ -21,9 +21,9 @@ This rule has been deprecated in favor of
 
 ---
 
-In order to make snapshot tests more managable and reviewable
+In order to make snapshot tests more manageable and reviewable
 `toMatchInlineSnapshot()` and `toThrowErrorMatchingInlineSnapshot` should be
-used to write the snapshots inline in the test file.
+used to write the snapshots' inline in the test file.
 
 ## Rule details
 

docs/rules/prefer-to-be-null.md

@@ -1,7 +1,7 @@
 # Suggest using `toBeNull()` (`prefer-to-be-null`)
 
 In order to have a better failure message, `toBeNull()` should be used upon
-asserting expections on null value.
+asserting expectations on null value.
 
 ## Rule details
 

docs/rules/prefer-to-be-undefined.md

@@ -1,7 +1,7 @@
 # Suggest using `toBeUndefined()` (`prefer-to-be-undefined`)
 
 In order to have a better failure message, `toBeUndefined()` should be used upon
-asserting expections on undefined value.
+asserting expectations on undefined value.
 
 ## Rule details
 

docs/rules/prefer-to-have-length.md

@@ -1,12 +1,12 @@
 # Suggest using `toHaveLength()` (`prefer-to-have-length`)
 
 In order to have a better failure message, `toHaveLength()` should be used upon
-asserting expectations on object's length property.
+asserting expectations on objects length property.
 
 ## Rule details
 
 This rule triggers a warning if `toBe()`, `toEqual()` or `toStrictEqual()` is
-used to assert object's length property.
+used to assert objects length property.
 
 ```js
 expect(files.length).toBe(1);

docs/rules/prefer-todo.md

@@ -5,7 +5,7 @@ will be highlighted in the summary output.
 
 ## Rule details
 
-This rule triggers a warning if empty test case is used without 'test.todo'.
+This rule triggers a warning if empty test cases are used without 'test.todo'.
 
 ```js
 test('i need to write this test');

docs/rules/require-to-throw-message.md

@@ -1,6 +1,6 @@
 # Require a message for `toThrow()` (`require-to-throw-message`)
 
-`toThrow()`, and its alias `toThrowError()`, are used to check if an error is
+`toThrow()` (and its alias `toThrowError()`) is used to check if an error is
 thrown by a function call, such as in `expect(() => a()).toThrow()`. However, if
 no message is defined, then the test will pass for any thrown error. Requiring a
 message ensures that the intended error is thrown.

docs/rules/require-top-level-describe.md

@@ -2,8 +2,8 @@
 
 Jest allows you to organise your test files the way you want it. However, the
 more your codebase grows, the more it becomes hard to navigate in your test
-files. This rule makes sure that you provide at least a top-level describe block
-in your test file.
+files. This rule makes sure you provide at least a top-level `describe` block in
+your test file.
 
 ## Rule Details
 

docs/rules/valid-expect-in-promise.md

@@ -5,10 +5,8 @@ promise
 
 ## Rule details
 
-This rule triggers a warning if,
-
-- test is having assertions in `then` or `catch` block of a promise
-- and that promise is not returned from the test
+This rule looks for tests that have assertions in `then` and `catch` methods on
+promises that are not returned by the test.
 
 ### Default configuration