3

I am writing Selenium automation against a React application. I would like to have unique IDs added to page elements I am testing.

I asked the developers but their response was that this was hard to do because of the dynamic nature of the React application.

I don't know React - is this likely true? Is it likely that they are truly prevented from adding a fixed ID? Could the issue be that QA needs to ask for a different attribute other than ID, perhaps? For example, should it be easy for them to add a data attribute such as data-qa-id?

2

No, that's not true at all; you can definitely add your own id attributes to elements rendered in React components. id is listed as a supported DOM attribute in the docs.

Yes, in cases where components are reused, the developers will have to allow for something unique to be passed in, but that's exactly how e.g. Material-UI already does this: https://material-ui.com/components/text-fields/#accessibility, so there are definitely existing patterns they can adopt for this.

It's also possible to add e.g. data- attributes to React components for testing purposes, e.g. here and here are examples where I've used them. I generally prefer that approach to using IDs (or e.g. classes) as selectors because then it's obvious in the component that this value is being relied on by something else, and shouldn't be changed without a corresponding update elsewhere, particularly as it sounds like you have separate dev and QA teams.

I'd go back and ask for more clarity on what they think the problem is.

-1

Indeed React uses IDs to do DOM manipulation and they should not be touched.

However, one can create any other attribute:

render () {
    return (
        <h1 data-hello={this.props.hello}>{this.props.title}</h1>
    );
}

Note: Selenium would not be the most appropriated tool to deal with React apps. For testing the React app itself, something as Enzyme allows you to render components as you wish and checking their behavior

it('renders three <Foo /> components', () => {
  const wrapper = shallow(<MyComponent />);
  expect(wrapper.find(Foo)).to.have.length(3);
});
  • I'd suggest removing the second part entirely; Selenium is a very reasonable tool to deal with React apps. Sure you can do lower-level (unit, some integration) tests with e.g. Enzyme rendering, but that doesn't preclude also doing E2E testing with a browser driver like Selenium. – jonrsharpe Aug 21 at 7:10
  • The second part is related to the problem, given the problem of uniquely identifying elements is related to the visibility scope. If I can render a component in isolation, I can use simpler locators, such as tag names (or React component names); on the other hand, loading the whole app tend to demand more work on locators. Note 1: I mentioned that "if you want to test the React app itself", Enzyme makes for sense - to test the frontend app with an E2E approach is both overkill and fragile to service dependencies (which does not happen with frontend testing). – João Farias Aug 21 at 7:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.