WebCommander - Website builder platform

Challenge

Site builders are deceptively hard to test. The user-facing surface is huge - every theme, every widget, every device size, every combination of them. A “tested” feature in isolation can still break the published site when combined with another widget on a particular theme at a particular viewport. Manual regression doesn’t scale, but naive end-to-end automation hits the same wall: there are simply too many combinations.

Approach

Split coverage into three layers, each catching a different class of bug:

• Component-level Playwright tests on the builder’s widget palette - every widget rendered in isolation against representative theme tokens, asserting the structural HTML it emits.
• Page-level smoke tests assembling a fixed set of representative pages, covering the common widget combinations.
• Visual regression on the published output for golden-path pages across desktop and mobile viewports, with carefully scoped diff tolerance so font-rendering noise didn’t flood the signal.

For data: built reusable fixtures that constructed pages via the builder’s own API rather than clicking through the UI - so test setup didn’t depend on the UI it was about to test.

Outcome

Caught a class of cross-widget interaction bugs that manual testing had historically missed. Visual regression became a regular signal in PRs rather than an after-the-fact check. Test authoring stopped being a wall that only the QA team could climb - devs picked up the framework and started adding cases alongside their feature work.

What I’d do differently

The visual regression baselines were the most painful part to maintain. Next time I’d invest earlier in a tighter scoping convention - explicit ignore regions for known-noisy elements, and a clearer review workflow for intentional diffs - to avoid the “baselines drifted again, who knows what’s actually changed” trap.