docs: use long options for consistency and readability

Author: nickserv

Diff for: docs/example-react-intl.mdx

@@ -141,4 +141,4 @@ the component in a way that will simulate the user behavior as much as posible.
 | Use strings from the default language      | Test is easy to read, and asserts expected default output. If you have variables in your strings, you can test that they work properly with correct output.                                                                                                                          | 1. Strings hardcoded into tests mean you have to update both tests and code for any copy changes. 2. If multiple elements have the same string/substring text, find-and-replace may be hard to use reliably.                                                          |
 | Mock the translation library               | If your library is difficult to use in the test environment, you can mock it so it is easier. For example, you can add the message ID as a data-attribute to the text so you can query by that.                                                                                      | Test code deviates from what runs in production. Tests may assert about message IDs but not enough about content, so errors are possible.                                                                                                                             |
 | Use translation library in tests           | Decouples strings from tests, so you can update the message files in one place without worrying about breaking tests. Can run tests in another language or multiple languages. `const buttonText = getNodeText(<FormattedMessage id="buttonText" defaultMessage="Hello Button" />);` | Overhead - it takes more lines of code to write the test, and you need to know the variables and message IDs to create the right strings. It's not obvious what the text actually is when you read the test code, making maintaining it harder.                       |
-| Use translation library + inline snapshots | Same as above, but by adding an inline snapshot of the string, you can read the test code and see what strings are in use, but easily update them with `jest -u` if the messages change. `expect(buttonText).toMatchInlineSnapshot("'My button text'")`                              | Tests are longer because of the extra lines. You can wrap up some of the translation-related code into a helper function to make it a little more inline-able and avoid repeating yourself, but you still need to know the message IDs and variables inside the test. |
+| Use translation library + inline snapshots | Same as above, but by adding an inline snapshot of the string, you can read the test code and see what strings are in use, but easily update them with `jest --updateSnapshot` if the messages change. `expect(buttonText).toMatchInlineSnapshot("'My button text'")`                | Tests are longer because of the extra lines. You can wrap up some of the translation-related code into a helper function to make it a little more inline-able and avoid repeating yourself, but you still need to know the message IDs and variables inside the test. |

Diff for: docs/marko-testing-library/api.mdx

@@ -294,8 +294,8 @@ You can turn off the automatic test cleanup by importing the following module:
 import '@marko/testing-library/dont-cleanup-after-each'
 ```
 
-With mocha you can use `mocha -r @marko/testing-library/dont-cleanup-after-each`
-as a shorthand.
+With mocha you can use
+`mocha --require @marko/testing-library/dont-cleanup-after-each` as a shorthand.
 
 If you are using Jest, you can include
 `setupFilesAfterEnv: ["@marko/testing-library/dont-cleanup-after-each"]` in your

Diff for: docs/marko-testing-library/setup.mdx

@@ -80,7 +80,7 @@ To run server-side Marko tests with `mocha` you can simply run the following
 command:
 
 ```console
-mocha -r marko/node-require
+mocha --require marko/node-require
 ```
 
 This enables the

Diff for: docs/nightwatch-testing-library/intro.mdx

@@ -14,7 +14,7 @@ in [Nightwatch](https://nightwatchjs.org) for end-to-end web testing.
 then just
 
 ```bash npm2yarn
-npm install -D @testing-library/nightwatch
+npm install --save-dev @testing-library/nightwatch
 ```
 
 - [nightwatch-testing-library on GitHub][gh]

Diff for: docs/react-testing-library/setup.mdx

@@ -478,7 +478,7 @@ do this with Jest's `setupFiles` configuration:
 Or with mocha's `-r` flag:
 
 ```
-mocha -r @testing-library/react/dont-cleanup-after-each
+mocha --require @testing-library/react/dont-cleanup-after-each
 ```
 
 Alternatively, you could import `@testing-library/react/pure` in all your tests
@@ -508,5 +508,5 @@ exports.mochaHooks = {
 And register it using mocha's `-r` flag:
 
 ```
-mocha -r ./mocha-watch-cleanup-after-each.js
+mocha --require ./mocha-watch-cleanup-after-each.js
 ```

Diff for: docs/webdriverio-testing-library/intro.mdx

@@ -14,7 +14,7 @@ queries in [WebdriverIO](https://webdriver.io/) for end-to-end web testing.
 then just
 
 ```bash npm2yarn
-npm install -D @testing-library/webdriverio
+npm install --save-dev @testing-library/webdriverio
 ```
 
 - [webdriverio-testing-library on GitHub][gh]