Web UI Testing: What to Test, the Best Front-End Tools, and a Working Example

Web UI testing checks the part of your application people actually touch: buttons, forms, menus, error messages and layouts. A back end can return perfect data and the release still fails if the "Pay now" button is hidden behind a cookie banner on phones. UI tests are the layer that catches that.

This guide explains what web UI testing covers, groups the main web front end testing tools by the layer they test, and walks through a Playwright UI test that checks form validation with role-based locators and runs at phone and desktop widths. Every example is JavaScript and runs against public practice sites on Playwright 1.62.

What Is Web UI Testing?

Web UI testing is the practice of verifying a website's user interface by interacting with it the way a person would: clicking, typing, resizing and navigating, then checking that the screen shows the right content, state and feedback. It covers behaviour, appearance and usability across browsers and screen sizes.

It sits on top of unit and API tests. Those prove the logic and data are right; UI tests prove a real user can reach and use them. Front-end testing is the broader term and also includes unit tests of JavaScript functions, but in practice most people searching for it want the UI layer.

What Web UI and Front-End Testing Covers

You don't need every row on day one. Start with the flows that make money (sign-up, login, checkout), then add the others where bugs have already escaped.

Web Front End Testing Tools by Layer

There is no single "best" front-end testing tool, because each layer needs a different kind of check. Here are the web front end testing tools teams most often choose for each one. If you are choosing a product, our automated UI testing software guide compares 10 free and paid tools.

End-to-end UI tools

Playwright drives Chromium, Firefox and WebKit with one API, waits for elements automatically and records a trace of every failed step. Cypress runs inside the browser with a friendly interactive runner and suits front-end developers testing their own app. Selenium and WebdriverIO both use the WebDriver protocol: Selenium has the widest language support, and WebdriverIO (JavaScript) adds native mobile testing through Appium. For a full comparison see automated web testing software.

Component testing tools

Component tests mount one piece of UI, such as a button, form or modal, without the rest of the app. Testing Library with Jest or Vitest renders components in a simulated DOM (jsdom), which is fast but isn't a real browser. Cypress component testing mounts components in a real browser. Playwright component testing does the same through the @playwright/experimental-ct-react and @playwright/experimental-ct-vue packages; as the names say, it is still experimental. Storybook interaction tests run play functions against your stories. More detail in the Playwright component testing guide.

Visual testing tools

Playwright's toHaveScreenshot() saves a baseline image on the first run and fails when a later run differs beyond a threshold. It's free and stores baselines in your repo. Percy and Applitools are paid subscriptions that add cloud review dashboards and smarter diffing, usually priced by screenshot or checkpoint volume. See Playwright visual regression testing.

Accessibility testing tools

axe-core is the open-source rules engine behind many accessibility checkers. The @axe-core/playwright package runs it inside any Playwright test, so a UI flow can also scan each page it visits. Lighthouse, built into Chrome DevTools, gives a quick accessibility audit of a single page. Automated rules catch common issues, not all of them, so keep some manual keyboard and screen-reader checks. See Playwright accessibility testing.

Web UI Testing Example in Playwright

This test file checks a login form on the Swag Labs practice site. It covers the empty-form error, a missing password and a successful login. Every element is found by its role and accessible name, the same way a screen reader finds it.

const { test, expect } = require('@playwright/test');

test.describe('login form UI', () => {
  test.beforeEach(async ({ page }) => {
    await page.goto('https://www.saucedemo.com/');
  });

  test('empty form shows a validation message', async ({ page }) => {
    await page.getByRole('button', { name: 'Login' }).click();
    await expect(page.locator('[data-test="error"]'))
      .toHaveText('Epic sadface: Username is required');
  });

  test('missing password is rejected', async ({ page }) => {
    await page.getByRole('textbox', { name: 'Username' }).fill('standard_user');
    await page.getByRole('button', { name: 'Login' }).click();
    await expect(page.locator('[data-test="error"]'))
      .toHaveText('Epic sadface: Password is required');
  });

  test('valid user reaches the products page', async ({ page }) => {
    await page.getByRole('textbox', { name: 'Username' }).fill('standard_user');
    await page.getByRole('textbox', { name: 'Password' }).fill('secret_sauce');
    await page.getByRole('button', { name: 'Login' }).click();
    await expect(page).toHaveURL(/inventory\.html/);
    await expect(page.getByText('Products')).toBeVisible();
  });
});

The error message is the one element without a useful role, so it uses the site's data-test attribute. That's an acceptable fallback: it's a stable hook added for testing, not a styling class.

Test responsive layouts with viewports

Responsive bugs are some of the most common UI failures. test.use({ viewport }) runs the same page at a phone width and a desktop width. On playwright.dev, the main navigation collapses into a menu button on narrow screens:

const { test, expect } = require('@playwright/test');

test.describe('phone width', () => {
  test.use({ viewport: { width: 375, height: 812 } });

  test('nav collapses into a menu button', async ({ page }) => {
    await page.goto('https://playwright.dev/');
    const nav = page.getByRole('navigation', { name: 'Main' });
    await expect(nav.getByRole('button', { name: 'Toggle navigation bar' })).toBeVisible();
    await expect(nav.getByRole('link', { name: 'Docs' })).toBeHidden();
  });
});

test.describe('desktop width', () => {
  test.use({ viewport: { width: 1280, height: 800 } });

  test('nav shows the full link list', async ({ page }) => {
    await page.goto('https://playwright.dev/');
    const nav = page.getByRole('navigation', { name: 'Main' });
    await expect(nav.getByRole('link', { name: 'Docs' })).toBeVisible();
    await expect(nav.getByRole('button', { name: 'Toggle navigation bar' })).toBeHidden();
  });
});

Run both files with npx playwright test:

Running 5 tests using 2 workers

  ✓  tests/responsive-nav.spec.js › phone width › nav collapses into a menu button
  ✓  tests/login-form-ui.spec.js › login form UI › empty form shows a validation message
  ✓  tests/responsive-nav.spec.js › desktop width › nav shows the full link list
  ✓  tests/login-form-ui.spec.js › login form UI › missing password is rejected
  ✓  tests/login-form-ui.spec.js › login form UI › valid user reaches the products page

  5 passed

To test real device profiles instead of a bare width, use devices['iPhone 13'] or devices['Pixel 7'] as projects in playwright.config.js, and add Firefox and WebKit projects for cross-browser coverage. The Playwright cross-browser testing guide has the full config.

Stable UI Locators: What to Use and What to Avoid

Most flaky UI tests aren't caused by the app. They're caused by locators that break when a designer renames a class. Prefer locators that describe what the user sees:

If getByRole can't find an element, that's often an accessibility bug worth reporting. More in the getByRole guide and the Playwright locators guide.

7 Common Web UI Testing Mistakes

1. Fixed sleeps. waitForTimeout(3000) is slow when the app is fast and flaky when it's slow. Use web-first assertions like toBeVisible(), which retry until they pass.
2. Brittle selectors. CSS classes and deep XPath tie tests to markup. Use roles, labels and text.
3. Testing everything through the UI. Business rules with many combinations belong in unit or API tests. Keep UI tests for journeys.
4. Only testing the happy path. Empty fields, wrong passwords and error banners are where users get stuck.
5. One browser, one width. Safari and phone layouts break most often, and they're the ones skipped.
6. Tests that depend on each other. Each test should set up its own state so it can run alone and in parallel.
7. Screenshots of everything. Visual tests on dynamic pages (dates, ads, carousels) fail constantly. Mask changing areas or snapshot stable components.

Where to Start

Pick three journeys that would cost the business most if they broke. Write one Playwright test for each, using role locators, and run them in Chromium, WebKit and a phone profile on every pull request. Add accessibility scans to those same tests, then visual checks on stable pages. For the broader picture, see how to test a web application, and if you want the same tool to automate non-testing browser tasks, read web automation tools compared.

Frequently Asked Questions

Meet Your Instructor

Asim Noaman

Senior QA Automation Engineer & AI Testing Specialist

With years of hands-on experience building test automation frameworks for production applications, Asim specializes in combining traditional QA methodologies with cutting-edge AI tools. He has helped teams adopt Playwright and AI-driven testing workflows to ship faster with fewer bugs.

Udemy Instructor Published course author

Playwright + AI Expert Specialized in AI-powered QA

Production Experience Enterprise-grade frameworks

Connect on LinkedIn