Help Choosing a Tool for UI Automation of a Product with React Front End?

Questions
#1

I saw this question pop up on the Ministry of Testing Slack for the third time in the past few weeks so thought it was definitely a conversation for The Club!

What tool would you advise to use for automation at the UI level of a product that has a React front end?

The person who inspired this post added that their

product is written in Javascript/nodejs and they use Enzyme/Jest for their unit test.

When I was working in a very similar situation, I chose webdriver.io for the job but I wondered if others would have different suggestions or an expansion on my own experience?

Nightwatchjs vs. WebdriverIO
#2

A few weeks back I was prompted on twitter to add to the discussion … I started writing something yesterday and then it ballooned! I’ll post it shortly :slight_smile:

1 Like
#3

Didn’t have time to finish, so I’ll publish as a blog post and share later.

For now…

I believe these are some of the more important things to consider:

  1. What do you actually want to test?

  2. How important is a tight test/debug/fix loop for you?

  3. Who’s going to write and maintain the tests?

  4. How important is x-browser/device execution?

  5. UI Automation can mean many different things. If it’s just basic functionality, then pretty much anything will be ok. If you want something that’s going to provide extra support for things like accessibility and client side performance, you might consider Cypress, Puppeteer or Playwright.

  6. If you want a really tight test/debug/fix loop then that tends to require tests that are really focussed on one specific aspect of ‘quality’ and are kept as far from the browser as possible. You mention Jest/Enzyme, which is typical for ‘code’ level tests. My preference these days is to use React Testing Library because it forces you to test behaviour rather than implementation, something the Jest/Enzyme pairing does a lot. Focussing ‘code’ level tests on behaviour helps us to find the gaps which can only really be found in a browser.

  7. If you want Devs to write UI level tests then you absolutely have to use the same language they do. For your case the examples I’ve provided are all JS, so that hurdle is covered. Additionally, you’d want to consider the interface, Devs tend to prefer code rather than interactive (in my experience) so leaning toward Puppeteer or Playwright might get you more traction. If however it’s the testers who are owning this work, Cypress is tough to look past because it’s been built to support interactive debugging, which definitely helps anyone who’s a little less confident in code only.

  8. The final big decision maker… x-browser/device support. My personal preference is to pick the right tool for the job so I’m happy with having RLT/JestEnzyme for ‘code’ level, Cypress for broad behaviour coverage and then webdriverio for specific cases which stress x-browser/device compatibility. Many don’t do this, and instead rely on webdriverio for all of their UI automation needs. That’s perfectly fine if it works for you in your context. Also consider: Playwright appears to be heading down a x-browser route, Cypress can execute in Chrome and Firefox. For styling risks I prefer to use Cypress with Applitools, which provides at least the ‘visual’ aspect for a reasonable x-browser/iPhone matrix. That still leaves JS execution, only Selenium based libraries can really do that well, at the moment.

Remember… Every tool has its limitations… Cypress doesn’t currently work with tabs. Most UI automation tools struggle with iFrames. Personally I try to refrain from worrying about these unless they’re a huge risk for the product I’m testing.

2 Likes