Theme switching and saved preferences look simple from a product perspective, but they are one of the fastest ways to expose weak assumptions in Test automation. A UI that remembers dark mode, density, language, sidebar collapse state, or notification preferences is not just rendering a screen, it is depending on browser storage, server-side profiles, hydration timing, and component state that may outlive a single page load.

That is where the comparison between Endtest and Playwright becomes interesting. Playwright is excellent when your team wants code-level control over application behavior and can afford to maintain that control. Endtest is stronger when the primary problem is stateful UI flows that change often, especially when visual regressions and locator churn are part of the cost of ownership. For teams testing theme switching, persisted UI state, and preference-driven screens, the real question is not which tool can click a toggle, it is which approach keeps those tests trustworthy and maintainable as the product evolves.

What makes persisted UI state hard to test

Persisted UI state is any state that survives a page reload, a browser restart, or a user session boundary. Common examples include:

  • Theme mode, for example light, dark, or system
  • Language or locale selection
  • Sidebar collapse or density preferences
  • Table column visibility and sorting
  • Feature-flagged UI variants tied to account settings
  • Notification dismissal state
  • Last visited tab or route

The technical difficulty is that each of these can be stored differently:

  • localStorage or sessionStorage
  • cookies
  • server-backed user profile settings
  • URL query parameters or path segments
  • IndexedDB for more complex client state
  • app-specific memory that is rehydrated after startup

A test that verifies only one toggle click is not enough. You usually need to validate at least three things:

  1. The user action changes state correctly.
  2. The state survives a refresh or new session.
  3. The UI renders the persisted state consistently after reload, navigation, or browser restart.

A common failure mode is to assert the toggle itself, but never the rehydrated UI after the app reloads. That can miss the real regression, where the setting saves correctly but is not re-applied on startup.

The practical difference between Endtest and Playwright

Playwright is a programmable browser automation library. Its official documentation describes it as a framework for reliable end-to-end testing across Chromium, Firefox, and WebKit, with strong control over browser context, storage, and assertions (Playwright docs). That makes it a good fit for teams that want to express persisted state tests in code and integrate them with existing engineering workflows.

Endtest is a managed, agentic AI test automation platform with low-code and no-code workflows. Its strength is not just that it can interact with the UI, but that it can reduce maintenance when locators, layouts, and visual presentation change frequently. Endtest also offers Self-Healing Tests, which automatically recover when locators break, and Visual AI for detecting meaningful visual regressions.

For theme switching and user preferences, the difference shows up in ownership:

  • Playwright gives you fine-grained state control, but your team owns the code, storage fixtures, browser setup, and maintenance.
  • Endtest gives you editable platform-native steps and managed execution, which can be a better fit when preference-driven UI is frequently redesigned or when non-developers need to author or maintain coverage.

How Playwright handles theme switching and persisted state

Playwright is strong at this kind of testing because it exposes the browser context directly. You can set up storage state, inspect cookies, clear browser data, and reload the page in a controlled way.

A typical flow for testing a persisted theme preference looks like this:

import { test, expect } from '@playwright/test';

test('persists dark mode preference across reload', async ({ page, context }) => {
  await page.goto('https://app.example.com');

await page.getByRole(‘button’, { name: /dark mode/i }).click(); await expect(page.locator(‘html’)).toHaveAttribute(‘data-theme’, ‘dark’);

await page.reload(); await expect(page.locator(‘html’)).toHaveAttribute(‘data-theme’, ‘dark’);

const storage = await context.storageState(); expect(storage.cookies.length).toBeGreaterThanOrEqual(0); });

This is straightforward when the app stores theme preference in a predictable place, such as a cookie or localStorage. If your app uses localStorage, Playwright can preload state before the test starts:

import { test, expect } from '@playwright/test';

test.use({ storageState: { cookies: [], origins: [] } });

test('starts in dark mode from saved storage', async ({ page }) => {
  await page.addInitScript(() => {
    localStorage.setItem('theme', 'dark');
  });

await page.goto(‘https://app.example.com’); await expect(page.locator(‘html’)).toHaveAttribute(‘data-theme’, ‘dark’); });

This is where Playwright excels, because it lets you design tests around the actual persistence mechanism. The tradeoff is that this code becomes part of your maintenance burden. When product teams rename storage keys, alter hydration timing, or move from localStorage to server-side preferences, the tests need to be updated in lockstep.

Playwright strengths for persisted UI state testing

  • Direct access to browser storage and cookies
  • Strong assertions around DOM state and network behavior
  • Easy to write negative tests, such as corrupted storage or missing preferences
  • Good fit for CI pipelines owned by engineering teams
  • Clear control over test isolation and session reuse

Playwright failure modes

  • Over-reliance on implementation details, such as a specific storage key
  • Test brittleness when UI labels or locators change
  • Fixture complexity as preference scenarios multiply
  • Maintenance load concentrated in a small group of developers or SDETs
  • Added overhead for browser setup, framework upgrades, and reporter configuration

If your team is comfortable maintaining code and wants to verify exact state transitions at the browser and storage layer, Playwright is a strong option. If the main pain is that these tests break too often because the UI changes every sprint, code control alone may not be enough.

How Endtest approaches the same problem

Endtest is often more attractive when the app under test changes visually and structurally at a high rate, but the team still needs dependable coverage for preferences and theme toggles. The platform is built around human-readable, editable steps rather than framework code, which makes the test intent easier to review and revise.

That matters for stateful UI testing because the hardest part is often not the assertion itself, it is keeping the locator stable as the product iterates. Endtest’s Self-Healing Tests documentation describes automatic recovery when locators break, reducing maintenance when UI elements move or attributes change. In practice, that can be a meaningful advantage for theme switching tests, where designers often adjust button labels, icons, menu structures, or component hierarchy while the underlying feature stays the same.

Endtest also supports Visual AI, which is useful when the regression risk is not just whether the theme preference persisted, but whether the UI actually looks correct after the switch. For example, dark mode regressions often include:

  • text contrast problems
  • invisible icons or borders
  • clipped content in cards or modals
  • unreadable charts or status badges
  • partial theme application across nested components

A functional assertion can confirm that the app says it is in dark mode. Visual validation can catch the cases where half the page failed to restyle.

Why Endtest can be lower-maintenance for this category of tests

  1. Stable intent, less code churn
    Preference tests are repetitive and often differ only by the setting under test. Human-readable steps are easier to refactor than a handful of framework-specific helpers copied across many files.

  2. Resilience to UI edits
    If a designer renames a menu item or restructures a settings panel, self-healing behavior can reduce the number of broken runs and red CI builds.

  3. Better fit for visual regressions
    Theme switching is partly visual. Endtest’s Visual AI is positioned to catch meaningful visual changes without requiring every pixel comparison to be hand-managed.

  4. Broader team ownership
    When QA, product, and design need to validate preference-driven behavior, a low-code platform can reduce dependency on a single framework owner.

For apps with frequent visual iteration, a test that survives minor locator and layout changes is often more valuable than a perfectly expressive code test that only one engineer can safely modify.

A practical comparison by test dimension

1. Validating the toggle action

If the goal is only to verify that a theme toggle can be clicked, both tools can do it. Playwright gives you precise control over the DOM and event timing. Endtest can model the interaction as a platform step.

The difference becomes visible when the control is not a simple toggle button, but a nested menu, a popover, or a responsive component that behaves differently on mobile and desktop. Endtest’s self-healing can reduce the cost of locator drift, while Playwright may require more frequent selector updates.

2. Verifying persistence after reload

Playwright is strongest when you need to inspect the exact persistence layer, for example reading cookies, setting localStorage, or waiting for a hydration event.

Endtest is stronger when the practical goal is, “does the user still see their preferred UI after reload?” without requiring the test author to script every detail of how the app stores it.

3. Testing multiple preference combinations

Preference matrices grow quickly:

  • dark mode + compact layout
  • dark mode + French locale
  • sidebar collapsed + notifications hidden
  • logged-in user A + feature flag B

Playwright is well suited to programmatic generation of these cases, especially if you already have a test data strategy. Endtest is often easier when the goal is a curated set of high-value user journeys rather than a large combinatorial matrix.

4. Catching visual regressions caused by theme changes

This is one of the strongest arguments for Endtest. Theme toggles are notorious for visual failures that pass functional assertions. A button can exist, a class can flip, and the app can still render badly.

Endtest’s Visual AI is directly aligned with that problem, because it validates what a user can actually see. Playwright can do screenshot comparison too, but it is still your team’s responsibility to manage baselines, false positives, thresholding, and test data hygiene.

5. Maintenance and ownership

Playwright maintenance costs are usually acceptable when tests are written by the same team that maintains the app. The framework lives close to the code, can be reviewed in pull requests, and can be refactored alongside application changes.

Endtest is attractive when you want to reduce framework ownership and keep the test representation more accessible. That can be a real advantage if the team needs to cover preference flows without turning every change into a code task.

Where each tool fits best

Choose Playwright when

  • your team wants code-first control over session state and storage
  • you need to validate persistence mechanisms directly
  • tests should run alongside application code in the same repo and review process
  • you already have strong TypeScript or Python test ownership
  • the UI is relatively stable, or your team is comfortable refactoring tests often

Choose Endtest when

  • the main pain is test maintenance, not lack of expressiveness
  • theme switching and preference screens change visually and structurally often
  • multiple team members need to read or adjust tests without learning a framework
  • you want self-healing locators and managed execution to reduce flake and upkeep
  • visual regression detection is a first-class requirement for preference-driven UI

A realistic hybrid strategy

Many teams do not need a pure choice. A practical test strategy for persisted UI state often uses both tools for different layers of confidence:

  • Playwright for a small set of deep, code-level checks around storage, API interactions, and edge-case state initialization
  • Endtest for broader user-flow coverage, visual validation, and lower-maintenance regression suites around theme switching and saved preferences

This split works especially well when the application uses a mix of client-side persistence and server-backed preferences. You can keep a few precise Playwright tests that inspect cookies or API responses, while using Endtest to validate that the interface still behaves correctly after the preference is applied.

A useful rule is this:

If the question is “did the browser store the right thing?”, Playwright is often the sharper tool. If the question is “does the user still get the right experience after the UI changed?”, Endtest can be the more sustainable choice.

Example test design for a dark mode regression suite

A solid suite does not try to test every combination exhaustively. It focuses on the changes most likely to break.

Core checks

  1. Enable dark mode from the settings menu.
  2. Reload the page and confirm dark mode remains active.
  3. Navigate to a second page and verify the theme persists.
  4. Open a modal, dropdown, or table view and check contrast and spacing.
  5. Sign out and confirm whether guest defaults differ from signed-in preferences, if applicable.

Edge cases worth including

  • first visit with no stored preference
  • stored preference missing or invalid
  • browser storage cleared mid-session
  • cross-tab behavior if the product syncs preference changes
  • mobile viewport versus desktop viewport
  • theme switch during hydration or initial loading state

Playwright can model each of these with direct control over the browser context. Endtest can cover the same user flows with less infrastructure overhead and, depending on your UI volatility, less maintenance friction.

CI/CD and operational considerations

Persisted state tests often fail for reasons that are not product defects:

  • shared browser state leaking between tests
  • flaky waits during hydration
  • stale locators after UI changes
  • visual diffs from unrelated content shifts
  • incorrect environment data, such as a missing feature flag

In CI/CD, this can become expensive because a red build caused by a brittle preference test blocks unrelated work. Playwright gives you the flexibility to tune isolation aggressively, but your team must own the tuning. Endtest’s managed execution and self-healing behavior reduce some of that overhead, which is valuable when the suite has to keep up with frequent releases.

If your team is evaluating total cost of ownership, do not stop at tool license or framework download size. Include:

  • engineering time to create and refactor tests
  • time spent on flaky-test triage
  • browser and CI infrastructure ownership
  • onboarding cost for new contributors
  • ownership concentration in a few specialists
  • the cost of visual regressions escaping into production

For a broader discussion of automation economics, Endtest also publishes How to Calculate ROI for Test Automation, which is relevant when you are deciding whether deeper framework ownership is justified.

Decision criteria you can actually use

If you are choosing between Endtest and Playwright for theme switching and persisted UI state testing, ask these questions:

  1. How often does the preference UI change?
    Frequent redesigns favor Endtest.

  2. Do we need direct access to storage and cookies?
    If yes, Playwright is likely necessary for at least some tests.

  3. Is visual correctness part of the acceptance criteria?
    If yes, Endtest’s Visual AI is especially relevant.

  4. Who will maintain the suite six months from now?
    If the answer is “a small group of framework experts,” Playwright may be fine. If the answer is “the broader team,” low-code maintainability matters more.

  5. Do we need coverage across multiple roles, not just developers?
    Endtest is usually easier for cross-functional ownership.

  6. Is the failure mode mostly locator churn or true logic bugs?
    Locator churn points toward Endtest. Logic bugs and data-state assertions often benefit from Playwright.

Final take

For theme switching, user preferences, and persisted UI state, the best tool depends on what kind of pain you are trying to remove.

Playwright is excellent when the team wants explicit control over browser state and is willing to maintain test code as part of the application engineering stack. It is a strong choice for precise validation of storage, reload behavior, and edge cases around browser context.

Endtest is especially compelling when the test problem includes UI volatility, visual regressions, and recurring maintenance work. Its agentic AI approach, self-healing locators, and Visual AI make it a credible lower-maintenance option for stateful UI flows that change frequently, which is exactly why it deserves serious consideration for preference-driven interfaces.

If your goal is durable coverage of persisted UI state with less upkeep, Endtest is often the more practical choice. If your goal is deep, code-level control over storage and browser behavior, Playwright remains a strong foundation. Many teams will get the best result by using both, each where it is strongest.