# Tips and Tricks
Sometimes, little changes can make a big difference in your project. Here are some test writing tips to keep everything running smoothly.
## Actions and action groups
### Use parameterized selectors in action groups with argument references
Clarity and readability are important factors in good test writing.
Having to parse through unreadable code can be time consuming. Save time by writing clearly.
The good example clearly shows what the selector arguments refer to.
In the bad example we see two parameters being passed into the selector with little clue as to their purpose.
**Why?** The next person maintaining the test or extending it may not be able to understand what the parameters are referencing.
Good
```xml
```
Bad
```xml
```
### Perform the most critical actions first in the `` block
Perform non-browser driving actions first. These are more likely to succeed as no UI is involved.
In the good example, `magentoCLI` and `deleteData` are run first to ensure a proper state.
In the bad example, we perform some heavy UI steps first.
**Why?** If something goes wrong there, then the critical `magentoCLI` commands may not get a chance to run, leaving Magento configured incorrectly for any upcoming tests.
Good:
```xml
```
Bad:
```xml
```
### When to use see vs. seeElement
Use `see` and `seeElement` wisely.
If you need to see some element and verify that the text inside is shown correctly, use the `see` action.
If you need to verify that element present on page, use `seeElement`.
But never use `seeElement` and build a xPath which contains the expected text.
**Why?** For `see` it will output something similar to this:
`Failed asserting that any element by #some_selector contains text "some_text"`
And for `seeElement` it will output something like this:
`Element by #some_selector is not visible.`
There is a subtle distinction: The first is a failure but it is the desired result: a 'positive failure'.
The second is a proper result of the action.
Good:
```xml
```
Bad:
```xml
```
### Always specify a default value for action group arguments
Whenever possible, specify a `defaultValue` for action group arguments.
GOOD:
```xml
```
BAD:
```xml
```
### Build tests from action groups
Build your tests using action groups, even if an action group contains a single action.
**Why?** For extension developers, this will make it easier to extend or customize tests.
Extending a single action group will update all tests that use this group.
This improves maintainability as multiple instances of a failure can be fixed with a single action group update.
GOOD:
```xml
```
BAD:
```xml
```
### Use descriptive stepKey names
Make `stepKeys` values as descriptive as possible.
Do not use numbers to make a `stepKey` unique.
**Why?** This helps with readability and clarity.
GOOD:
```xml
```
BAD:
```xml
```
**Exception:**
Use numbers within `stepKeys` when order is important, such as with testing sort order.
```xml
```
## Selectors
### Use contains() around text()
When possible, use `contains(text(), 'someTextHere')` rather than `text()='someTextHere'`.
`contains()` ignores whitespace while `text()` accounts for it.
**Why?**
If you are comparing text within a selector and have an unexpected space, or a blank line above or below the string, `text()` will fail while the `contains(text())` format will catch it.
In this scenario `text()` is more exacting. Use it when you need to be very precise about what is getting compared.
GOOD:
`//span[contains(text(), 'SomeTextHere')]`
BAD:
`//span[text()='SomeTextHere']`
### Build selectors in proper order
When building selectors for form elements, start with the parent context of the form element.
Then specify the element `name` attribute in your selector to ensure the correct element is targeted.
To build a selector for an input, use the pattern: `{{section_selector}} {{input_selector}}` or for a button: `{{section_selector}} {{button_selector}}`
**Why?** Traversing the DOM takes a finite amount of time and reducing the scope of the selector makes the selector lookup as efficient as possible.
Example:
```xml
```
GOOD:
```xml
```
BAD:
```xml
```
## General tips
### Use data references to avoid hardcoded values
If you need to run a command such as ``, do not hardcode paths and values to the command.
Rather, create an appropriate `ConfigData.xml` file, which contains the required parameters for running the command.
It will simplify the future maintanence of tests.
GOOD:
```xml
```
BAD:
```xml
```
For example:
[This test][] refers to this [Data file][].
### Use descriptive variable names
Use descriptive variable names to increase readability.
**Why?** It makes the code easier to follow and update.
GOOD:
```xml
```
BAD:
```xml
```
### Use proper checkbox actions
When working with input type `checkbox`, do not use the `click` action; use `checkOption` or `uncheckOption` instead.
**Why?** A click does not make it clear what the ending state will be; it will simply toggle the current state. Using the proper actions will ensure the expected state of the checkbox.
GOOD:
```xml
```
BAD:
```xml
```
[This test]: https://github.com/magento/magento2/blob/2.3-develop/app/code/Magento/Captcha/Test/Mftf/Test/StorefrontCaptchaRegisterNewCustomerTest.xml#L24
[Data file]: https://github.com/magento/magento2/blob/2.3-develop/app/code/Magento/Captcha/Test/Mftf/Data/CaptchaConfigData.xml