'Why remove QA IDs from the code base in production

In a React application that we are developing we use QA IDs for Selenium tests.

Is it bad practice to leave them in the code base in production (live)?

If so, why? Is it only to try to keep the TTFB (time to first byte) low?

More context:

  • Util for automation tags that takes a given string and returns an object containing properties to be spread onto an element. These should only be used for testing purposes as they should only be available during a test run.

Eg.

const automationTags = (givenTag) =>
  (IS_PROD || !givenTag) ? {} : { 'data-qa': _.kebabCase(givenTag) }

Usage:

  • <Component {...automationTags(`${dataQa}-button`)} />
  • <Component {...automationTags('profile-page-success-btn')} />

...where dataQa is the prop used within React components.

htmlreactjsseleniumtesting


Solution 1:[1]

I can see a number of reasons for leaving the ID's in.

  1. It reduces the complexity of the code. Rather than having all this logic all over the code base whether or not to include the ID's, the ID simply exists. It may be easy to remove them, but when you multiply the number of ID's, that is a lot of code included for little to no benefit.

  2. It increases the fidelity between the various environments. When you run the automation tests against your test environments, you can be fairly certain it will be the same code that is going to production and not another variation of it.

  3. It allows you to run automation against the production environment. Rather than assuming it works after a deploy, you now know it works. You know what they say about assuming right?

  4. It's not like the ID's can be abused by your customers. If your customers are inspecting the pages/code, simply knowing the ID's of the elements is not harmful.

  5. Rather than having to include specific QA ID's, maybe it would be a good practice to simply use actual ID's, class names and regular CSS so you don't need specific QA ID's

All of the above more than weigh up for the risk of leaving them in. I wouldn't think any performance gain would be measurable.

Having said that, actually measuring it would be the best way to convince the developers they don't need to remove them. For instance, Chrome's Developer Console has a way to measure the page load, and where the resources are going. If you go to Performance, you can record a page load and see what it takes to load a page. Comparing production with Test environments should give you more information.

Sources

This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.

Source: Stack Overflow

Solution Source
Solution 1 Arild Andreassen

Related Questions