Skip to main content
Version: Next

End-to-End Testing

Apache Superset uses Playwright for end-to-end testing, migrating from the legacy Cypress tests.

Running Tests​

cd superset-frontend

# Run all tests
npm run playwright:test
# or: npx playwright test

# Run specific test file
npx playwright test tests/auth/login.spec.ts

# Run with UI mode for debugging
npm run playwright:ui
# or: npx playwright test --ui

# Run in headed mode (see browser)
npm run playwright:headed
# or: npx playwright test --headed

# Debug specific test file
npm run playwright:debug tests/auth/login.spec.ts
# or: npx playwright test --debug tests/auth/login.spec.ts

Cypress (Deprecated)​

Cypress tests are being migrated to Playwright. For legacy tests:

cd superset-frontend/cypress-base
npm run cypress-run-chrome    # Headless
npm run cypress-debug         # Interactive UI

Project Architecture​

superset-frontend/playwright/
├── components/core/     # Reusable UI components
├── pages/              # Page Object Models
├── tests/              # Test files organized by feature
├── utils/              # Shared constants and utilities
└── playwright.config.ts

Design Principles​

We follow YAGNI (You Aren't Gonna Need It), DRY (Don't Repeat Yourself), and KISS (Keep It Simple, Stupid) principles:

  • Build only what's needed now
  • Reuse existing patterns and components
  • Keep solutions simple and maintainable

Page Object Pattern​

Each page object encapsulates:

  • Actions: What you can do on the page
  • Queries: Information you can get from the page
  • Selectors: Centralized in private static SELECTORS constant
  • NO Assertions: Keep assertions in test files

Example Page Object:

export class AuthPage {
  // Selectors centralized in the page object
  private static readonly SELECTORS = {
    LOGIN_FORM: '[data-test="login-form"]',
    USERNAME_INPUT: '[data-test="username-input"]',
  } as const;

  // Actions - what you can do
  async loginWithCredentials(username: string, password: string) {}

  // Queries - information you can get
  async getCurrentUrl(): Promise<string> {}

  // NO assertions - those belong in tests
}

Example Test:

import { test, expect } from '@playwright/test';
import { AuthPage } from '../../pages/AuthPage';
import { LOGIN } from '../../utils/urls';

test('should login with correct credentials', async ({ page }) => {
  const authPage = new AuthPage(page);
  await authPage.goto();
  await authPage.loginWithCredentials('admin', 'general');

  // Assertions belong in tests, not page objects
  expect(await authPage.getCurrentUrl()).not.toContain(LOGIN);
});

Core Components​

Reusable UI interaction classes for common elements (components/core/):

  • Form: Container with properly scoped child element access
  • Input: Supports fill(), type(), and pressSequentially() methods
  • Button: Standard click, hover, focus interactions

Usage Example:

import { Form } from '../components/core';

const loginForm = new Form(page, '[data-test="login-form"]');
const usernameInput = loginForm.getInput('[data-test="username-input"]');
await usernameInput.fill('admin');

Test Reports​

Playwright generates multiple reports for better visibility:

# View interactive HTML report (opens automatically on failure)
npm run playwright:report
# or: npx playwright show-report

# View test trace for debugging failures
npx playwright show-trace test-results/[test-name]/trace.zip

Report Types​

  • List Reporter: Shows progress and summary table in terminal
  • HTML Report: Interactive web interface with screenshots, videos, and traces
  • JSON Report: Machine-readable format in test-results/results.json
  • GitHub Actions: Annotations in CI for failed tests

Debugging Failed Tests​

When tests fail, Playwright automatically captures:

  • Screenshots at the point of failure
  • Videos of the entire test run
  • Traces with timeline and network activity
  • Error context with detailed debugging information

All debugging artifacts are available in the HTML report for easy analysis.

Configuration​

  • Config: playwright.config.ts - matches Cypress settings
  • Base URL: http://localhost:8088 (assumes Superset running)
  • Browsers: Chrome only for Phase 1 (YAGNI)
  • Retries: 2 in CI, 0 locally (matches Cypress)

Contributing Guidelines​

Adding New Tests​

  1. Check existing components before creating new ones
  2. Use page objects for page interactions
  3. Keep assertions in tests, not page objects
  4. Follow naming conventions: feature.spec.ts

Adding New Components​

  1. Follow YAGNI: Only build what's immediately needed
  2. Use Locator-based scoping for proper element isolation
  3. Support both string selectors and Locator objects via constructor overloads
  4. Add to components/core/index.ts for easy importing

Adding New Page Objects​

  1. Centralize selectors in private static SELECTORS constant
  2. Import shared constants from utils/urls.ts
  3. Actions and queries only - no assertions
  4. Use existing components for DOM interactions

Migration from Cypress​

When porting Cypress tests:

  1. Port the logic, not the implementation
  2. Use page objects instead of inline selectors
  3. Replace cy.intercept/cy.wait with page.waitForRequest()
  4. Use shared constants from utils/urls.ts
  5. Follow the established patterns shown in tests/auth/login.spec.ts

Best Practices​

  • Centralize selectors in page objects
  • Centralize URLs in utils/urls.ts
  • Use meaningful test descriptions
  • Keep page objects action-focused
  • Put assertions in tests, not page objects
  • Follow the existing patterns for consistency