Skip to content

E2E Testing Overview

CWIQ uses Playwright v1.58.2 for end-to-end testing of the Orchestrator UI. Tests live in platform/ui/e2e/ and run automatically after every successful deployment to DEV.

End-to-end tests verify the UI works correctly from a user's perspective — logging in, navigating pages, submitting forms, and confirming that the frontend and backend integrate correctly. They complement unit and integration tests by exercising the full stack through a real browser.

Test Targets

Environment URL When Used
CI (main branch) https://orchestrator.dev.cwiq.io After every successful deploy-dev
Local development http://localhost:3000 When running tests against a local stack

The target URL is controlled by the PLAYWRIGHT_BASE_URL environment variable. In CI, this is set to the VPC private IP of the DEV server (see CI Integration).

Test Projects

Playwright is configured with two test projects to separate authenticated and unauthenticated test scenarios.

Project Browser State Matches
authenticated Saved auth state from .auth/admin.json All tests by default
unauthenticated Clean session — no cookies, no storage Files matching */(login\|register\|public).*

Most tests run under the authenticated project. The global setup script logs in once before the test suite starts and saves the session to .auth/admin.json. Individual tests then reuse that saved state instead of repeating the login flow.

The unauthenticated project deliberately uses a clean browser session. It is the correct context for testing the login page, registration flow, and any public-facing pages that must be accessible without credentials.

Directory Structure

platform/ui/e2e/
├── fixtures/           # Test fixtures (auth context, org context, test data factories)
├── helpers/            # API helper functions for setting up test data via HTTP
├── pages/              # Page Object Model classes, one per page or major component
├── specs/              # Test specification files
│   ├── auth/           # Login, logout, session expiry
│   ├── admin/          # Admin panel — user management, org settings
│   ├── workflows/      # Workflow creation, execution, run history
│   └── ...
└── global-setup.ts     # Runs once before the entire suite — authenticates and saves state

The specs/ directory mirrors the application's navigation structure. When adding tests for a new feature, create the spec file in the subdirectory that matches the UI section it tests.

How Authentication Works

Because most tests require a logged-in user, the test suite avoids repeating the login UI flow for every test. Instead:

  1. global-setup.ts runs once before any test.
  2. It calls the backend login API directly (POST /api/v1/auth/login).
  3. It constructs a Zustand persist storage entry matching the shape the UI stores in localStorage.
  4. It saves the result to .auth/admin.json.
  5. All tests in the authenticated project load that saved state, starting each test already logged in.
sequenceDiagram
    participant GS as global-setup.ts
    participant API as Backend API
    participant FS as .auth/admin.json
    participant TEST as Test (authenticated project)

    GS->>API: POST /api/v1/auth/login
    API-->>GS: access_token + user data
    GS->>FS: Write Zustand localStorage state
    TEST->>FS: Load saved storage state
    TEST-->>TEST: Start test already logged in

ReportPortal Integration

Test results from CI runs are sent to ReportPortal in real time during the pipeline.

ReportPortal reporting is enabled only when the RP_ENDPOINT environment variable is set. It activates automatically in CI and is silently disabled when running tests locally. See ReportPortal for configuration details.

Pipeline Behaviour

The E2E test job runs in the verify stage, after verify-dev confirms the deployment is healthy.

flowchart LR
    DD[deploy-dev] --> VD[verify-dev] --> E2E[e2e-test<br/>allow_failure: true]

Key pipeline constraints:

  • Runs only on the main branch — not on feature branches.
  • allow_failure: true — E2E failures are reported but do not block the pipeline or prevent a green status on main.
  • Artifacts (HTML report, screenshots, videos, JUnit XML) are retained for two weeks.

Why allow_failure: true?

E2E tests can be flaky due to timing, network conditions, or test environment state. Setting allow_failure: true prevents intermittent test failures from blocking main. Investigate failures in ReportPortal after each run, but do not treat every E2E failure as a deployment blocker.