Pitfalls Encountered in Frontend Automation Testing

@ Software Testing

Introduction

The ever-changing complexity of frontend UI has undergone various iterations and ups and downs in tools, such as:

  • Early browser standards from chaos to stability
  • Lack of comprehensive testing tools to the current rich testing ecosystem
  • Changes in CSS management methodologies (BEM, OOCSS… -> Utility First)
  • Early jQuery imperative DOM manipulation transitioning to modern declarative component frameworks like React and Vue
  • From pre-styled libraries (Chakra🔗, AntD🔗, Bootstrap🔗) to the rise of headless frameworks (zag🔗, React Aria🔗, Radix UI🔗)

After experiencing numerous ups and downs, this article records how to build efficient and maintainable frontends at this stage.

Pitfall One: Testing Built on Unstable Foundations

Creating custom UI seems simple, but handling edge cases (such as browser differences, accessibility a11y, keyboard operations) is extremely complex.

Most of the time, there’s no need to create an overly common UI; many interfaces may appear simple but can be hell to maintain. Browser differences, version issues, and complex environments come with too many variables in the web environment. For example: Radix, a seemingly simple Dropdown Menu, spent months with thousands of commits refining it.

Establishing tests comes at a cost, and automated tests should focus on generating value-driven code: “Is the business logic behaving correctly and verifiable automatically?”

Pitfall Two: The Dilemma of Speed and Confidence

Web pages run in a browser environment, so naturally, testing mimics the browser, which is the strength of traditional E2E testing solutions like Cypress🔗 and Playwright🔗. The other direction is simulating a browser environment and API using jsdom🔗 to achieve web page testing in a Node.js environment.

  • Simulating a real browser is always too slow and too costly.
  • Simulating a fake browser environment introduces many discrepancies compared to a real browser.
    • I cannot express how frustrating it is when a slight difference in a jsdom-simulated browser can lead to hours of debugging. Many strange issues will really require referencing mature large project testing code like Reka UI🔗 to know which workarounds are necessary.

This is why Cypress Component Testing🔗, Playwright Components🔗, and Vitest Browser Mode🔗 have emerged, to find a better balance between “speed” and “confidence” in modern web testing. These technologies are still in the experimental phase. Understanding the purpose of testing and the differences in tools is crucial for making trade-offs.

Pitfall Three: Forgotten Tests

Many projects write tests, but because they are too slow or too unstable (Flaky), it leads to:

  • False Tests: An unstable test can erode team confidence more severely than having no tests at all.
  • Tests only hold value when executed: The summary of my testing experience from my previous job explains why software should be tested.
  • Feedback Speed: Allowing tests to run quickly encourages developers to execute them frequently during development.

Further Reading