Skip to content

Fixed several typos in docs #1707

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Oct 24, 2022
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions docs/QUnit/module.md
Original file line number Diff line number Diff line change
Expand Up @@ -25,7 +25,7 @@ Group related tests under a common label.

All tests inside a module will be grouped under that module. Tests can be added to a module using the [QUnit.test](./test.md) method. Modules help organize, select, and filter tests to run. See [§ Organizing your tests](#organizing-your-tests).

Modules can be nested inside other modules. In the output, tests are generally prefixed by the names of all parent modules. E.g. "Grantparent > Parent > Child > my test". See [§ Nested module scope](#nested-module-scope).
Modules can be nested inside other modules. In the output, tests are generally prefixed by the names of all parent modules. E.g. "Grandparent > Parent > Child > my test". See [§ Nested module scope](#nested-module-scope).

The `QUnit.module.only()`, `QUnit.module.skip()`, and `QUnit.module.todo()` methods are aliases for `QUnit.module()` that apply the behaviour of [`QUnit.test.only()`](./test.only.md), [`QUnit.test.skip()`](./test.skip.md) or [`QUnit.test.todo()`](./test.todo.md) to all a module's tests at once.

Expand Down Expand Up @@ -76,7 +76,7 @@ Example: [§ Declaring module options](#declaring-module-options).

### Nested scope

Modules can be nested to group tests under under a commmon label within a parent module.
Modules can be nested to group tests under a common label within a parent module.

The module scope is given a `hooks` object which can be used to procedurally add [hooks](#hooks).

Expand Down
2 changes: 1 addition & 1 deletion docs/_data/sidebar_api.yml
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,7 @@

- group: async
# These pages are all in at least one other group.
# It exisxts for discoverability, but we don't need
# It exists for discoverability, but we don't need
# to highlight its pages in two places.
expand: false

Expand Down
2 changes: 1 addition & 1 deletion docs/assert/notPropEqual.md
Original file line number Diff line number Diff line change
Expand Up @@ -19,7 +19,7 @@ Compare an object's own properties using a strict inequality comparison.
| `expected` | Known comparison value |
| `message` (string) | Short description |

The `notPropEqual` assertion compares only an object's own properties, using the strict inquality operator (`!==`).
The `notPropEqual` assertion compares only an object's own properties, using the strict inequality operator (`!==`).

The test passes if there are properties with different values, or extra properties, or missing properties.

Expand Down
2 changes: 1 addition & 1 deletion docs/assert/verifySteps.md
Original file line number Diff line number Diff line change
Expand Up @@ -54,7 +54,7 @@ QUnit.test('good example', async assert => {
});
```

When approaching this scenario **without the Step API** one might be tempted to place comparison checks directly inside event callbacks. It is considered an anti-pattern to make dummy assertions in callbacks that the test does not have control over. This creates loose assurances, and can easily cause false positives (a callback might not run, run out of order, or run multipe times). It also offers rather limited debugging information.
When approaching this scenario **without the Step API** one might be tempted to place comparison checks directly inside event callbacks. It is considered an anti-pattern to make dummy assertions in callbacks that the test does not have control over. This creates loose assurances, and can easily cause false positives (a callback might not run, run out of order, or run multiple times). It also offers rather limited debugging information.

```js
// WARNING: This is a BAD example
Expand Down
2 changes: 1 addition & 1 deletion docs/callbacks/QUnit.moduleDone.md
Original file line number Diff line number Diff line change
Expand Up @@ -27,7 +27,7 @@ Passed to the callback:
| `failed` (number) | The number of failed assertions |
| `passed` (number) | The number of passed assertions |
| `total` (number) | The total number of assertions |
| `runtime` (number) | The execution time in millseconds of this module |
| `runtime` (number) | The execution time in milliseconds of this module |

## Examples

Expand Down
2 changes: 1 addition & 1 deletion docs/callbacks/QUnit.on.md
Original file line number Diff line number Diff line change
Expand Up @@ -122,7 +122,7 @@ QUnit.on('testEnd', testEnd => {

The `runEnd` event indicates the end of a test run. It is emitted exactly once.

| `string` | `status` | Aggregate result of all tests, one of:<br>`failed`: at least one test failed or a global error ocurred;<br>`passed`: there were no failed tests, which means there were only tests with a passed, skipped, or todo status. If [`QUnit.config.failOnZeroTests`](../config/failOnZeroTests.md) is disabled, then the run may also pass if there were no tests.
| `string` | `status` | Aggregate result of all tests, one of:<br>`failed`: at least one test failed or a global error occurred;<br>`passed`: there were no failed tests, which means there were only tests with a passed, skipped, or todo status. If [`QUnit.config.failOnZeroTests`](../config/failOnZeroTests.md) is disabled, then the run may also pass if there were no tests.
| `Object` | `testCounts` | Aggregate counts about tests:
| `number` | `testCounts.passed` | Number of passed tests.
| `number` | `testCounts.failed` | Number of failed tests.
Expand Down
2 changes: 1 addition & 1 deletion docs/callbacks/QUnit.testDone.md
Original file line number Diff line number Diff line change
Expand Up @@ -28,7 +28,7 @@ Passed to the callback:
| `failed` (number) | The number of failed assertions |
| `passed` (number) | The number of passed assertions |
| `total` (number) | The total number of assertions |
| `runtime` (number) | The execution time in millseconds of the test, including beforeEach and afterEach calls |
| `runtime` (number) | The execution time in milliseconds of the test, including beforeEach and afterEach calls |
| `skipped` (boolean) | Indicates whether or not the current test was skipped |
| `todo` (boolean) | Indicates whether or not the current test was a todo |

Expand Down
2 changes: 1 addition & 1 deletion docs/config/hidepassed.md
Original file line number Diff line number Diff line change
Expand Up @@ -22,4 +22,4 @@ In the HTML Reporter, hide results of passed tests.

<p class="note" markdown="1">This option can also be controlled via the [HTML Reporter](https://qunitjs.com/intro/#in-the-browser).</p>

By default, the HTML Reporter will list (in collapsd form) the names of all passed tests. Enable this option, to only list failing tests.
By default, the HTML Reporter will list (in collapsed form) the names of all passed tests. Enable this option, to only list failing tests.