Exploring Robust Browser and Component Testing Solutions for Large-Scale Frontend Teams

In the realm of enterprise frontend development, ensuring reliable and comprehensive component testing is critical. Our team, comprising approximately 50 frontend engineers working with a Vue, TypeScript, and Vite-based monolith, faces ongoing challenges with current testing methodologies.

Presently, we utilize Vitest combined with Testing Library and JSDom for unit and integration tests. However, the experience often falls short—testing within synthetic environments complicates the creation of intricate interactions and provides limited CSS visualization. Additionally, we seek a testing process that offers visual debugging capabilities to better understand test failures.

In a previous role, I implemented Cypress Component Testing, which produced promising results and encouraged better component encapsulation and cleanliness. Nevertheless, the maturity of Cypress’s component testing ecosystem remains a concern, especially considering recent controversies around the tool. As a result, we’re exploring alternative solutions that meet the following criteria:

• Support testing within real browsers such as Chrome, Safari, and Firefox
• Allow control or stubbing of network requests for complete isolation
• Incorporate a modular mocking system
• Provide both headed (UI) and headless execution modes
• Utilize a familiar syntax derived from Playwright or Testing Library

Our current options include:

Playwright Component Testing
https://playwright.dev/docs/test-components
While Playwright has been available in an experimental capacity for some years, it offers robust features aligned with our needs. That said, I have yet to evaluate its maturity and stability within the Vue ecosystem extensively.

Vitest Browser Testing
https://vitest.dev/guide/browser/
Vitest’s browser testing support is still in the experimental stage. I’ve experimented with a quick proof of concept, but I find its UI controls somewhat rudimentary, potentially limiting for larger teams.

Storybook Component Testing
https://storybook.js.org/blog/component-testing/
While leveraging Storybook for component creation and snapshot testing aligns well with our workflow, scaling to hundreds of tests by turning each into a Story raises concerns about performance and longer build times. Additionally, the current mocking system requires cumbersome modifications to package.json, which hampers ease of use.

Your Insights Needed
For organizations with large teams (30+ developers) that have adopted these testing tools, I welcome any