quine-global/webdriverio
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

fix(docs): correct typos and improve clarity in Best Practices guide (#14615)

Browse source
This commit is contained in:
Agnes Au 2025-07-08 01:33:43 +08:00 committed by GitHub
parent 97acfadd2d
commit 96489ee4f2
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
1 changed files with 6 additions and 6 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

12
website/docs/BestPractices.md
View file

@ -92,7 +92,7 @@ await expect(button).toBeDisplayed()
## Lazy loading and promise chaining
WebdriverIO has some tricks up it's sleeve when it comes to writing clean code as it can lazy load the element which allows you to chain your promises and reduces the amount of `await`. This also allows you to pass the element as a ChainablePromiseElement instead of an Element and for easier use with page objects.
WebdriverIO has some tricks up its sleeve when it comes to writing clean code as it can lazy load the element which allows you to chain your promises and reduces the amount of `await`. This also allows you to pass the element as a ChainablePromiseElement instead of an Element and for easier use with page objects.
So when do you have to use `await`?
You should always use `await` with the exception of the `$` and `$$` command.
@ -131,7 +131,7 @@ await expect(button).toBeDisplayed()
await expect(button).toBeDisplayed()
```
No need to wait for an element to exist or be displayed when interacting or when asserting something like it's text unless the element can explicitly be invisible (opacity: 0 for example) or can explicitly be disabled (disabled attribute for example) in which case waiting for the element to be displayed makes sense.
No need to wait for an element to exist or be displayed when interacting or when asserting something like its text unless the element can explicitly be invisible (opacity: 0 for example) or can explicitly be disabled (disabled attribute for example) in which case waiting for the element to be displayed makes sense.
```js
// 👎
@ -161,11 +161,11 @@ Use environment variables to store dynamic test data e.g. secret credentials, wi
## Lint your code
Using eslint to lint your code you can potentionally catch errors early, use our [linting rules](https://www.npmjs.com/package/eslint-plugin-wdio) to make sure that some of the best practices are always applied.
Using eslint to lint your code you can potentially catch errors early, use our [linting rules](https://www.npmjs.com/package/eslint-plugin-wdio) to make sure that some of the best practices are always applied.
## Don't pause
It can be tempting to use the pause command but using this is a bad idea as it isn't resilient and will only cause for flaky tests in the long run.
It can be tempting to use the pause command but using this is a bad idea as it isn't resilient and will only cause flaky tests in the long run.
```js
// 👎
@ -184,11 +184,11 @@ await submitFormButton.click()
When you have some asynchronous code that you want to repeat, it is important to know that not all loops can do this.
For example, the Array's forEach function does not allow for asynchronous callbacks as can be read over on [MDN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/forEach).
__Note:__ You can still use these when you do not need the operation to be synchronous like in shown in this example `console.log(await $$('h1').map((h1) => h1.getText()))`.
__Note:__ You can still use these when you do not need the operation to be asynchronous like in shown in this example `console.log(await $$('h1').map((h1) => h1.getText()))`.
Below are some examples of what this means.
The following will not work as asynchronous callback are not supported.
The following will not work as asynchronous callbacks are not supported.
```js
// 👎