Should ‘qa’ classes be applied to JS components for automation test purposes?
We currently have a suite of automation tests written in cucumber JS using the gherkin syntax, which are run against our ReactJs app. In the majority of cases we are using a css selector within our feature step to assert against something on the page. But should we be adding ‘qa’ classes to these elements so we can select them within the automation test environment?
- Selectors within the feature steps will be simple:
- Conventions, (such as BEM), can be applied to qa classes for consistent naming.
- Not relying on nested DOM structure selectors means changes to the components DOM can be made without breaking the tests, making them less brittle.
client.getText('body > div.nav > div > p > span').then(...);
- Not relying on style class names means styling changes can occur without the risk of breaking tests.
- Developers will not be tempted to use inappropriate class names for selectors, e.g. utility class names (.u-small-padding-right).
- You have to add ‘test’ code, (qa class names), to your source.
Linting ‘qa’ classes in test steps
A linting tool can be added within your build process to make sure developers are using the correct ‘qa’ class names in their test selectors. This will police the code within the feature steps and guarantee no other style classes or query/id selectors are used.
Removal of ‘qa’ classes at build time
To reduce the payload of the production application it may be advised that these ‘qa’ classes are removed from the bundled production build. HTML sanitiser tools such as sanitize-html may be used to remove any unwanted class names from HTML.
With so few disadvantages to adding qa class names to application code for automation test purposes I see no reason why they should not be used. Are there other factors which I should be addressing?