WrightTest is a self-hosted platform for creating and running browser UI tests. It wraps Playwright in a web UI, so you can click through your app via a live browser session, capture steps, run them headlessly and review results with per-step screenshots and traces. Most tests require no hand-written code.
Quick start
Three commands and the app is ready
# Three commands to start
git clone github.com/AlexFilippov-it/wrighttest
cp .env.example .env # set JWT_SECRET
docker compose up --buildWhat is WrightTest
WrightTest sits between manual testing and a full automation framework. It lets QA engineers and developers create reliable Playwright browser tests through a web UI without maintaining a Node.js test project or writing test blocks from scratch.
The recorder opens a real Chromium browser via noVNC, visible directly in the browser window. Under the hood it runs playwright codegen, which generates role-based locators like getByRole, getByLabel and getByTestId instead of fragile CSS paths.
Tests run headlessly on the server through a BullMQ queue backed by Redis. Each run produces per-step screenshots, a Playwright trace archive, and a pass or fail result accessible via polling or webhook.
A test can target a specific device such as iPhone 15, Pixel 7 or iPad Pro. Playwright applies the correct viewport, user agent and touch events. This is browser emulation, not testing on physical devices.
Any test recorded in the UI can be exported as a standard Playwright test file. The exported file runs with npx playwright test in any CI pipeline without WrightTest installed, so there is no vendor dependency.
How it works
WrightTest connects the visual recording session to the headless runner through a job queue, so browser interaction and test execution are fully decoupled.
User enters a start URL and clicks Start Recording. A real Chromium window appears in the noVNC iframe. Playwright codegen captures every click, fill and navigation as a structured step.
Recorded steps appear in the visual editor. The user can add assertions such as toBeVisible, toHaveText and toHaveURL, insert environment variables like {{BASE_URL}}, reorder or delete steps before saving.
Clicking Run places a job in the BullMQ queue. The worker picks it up, launches headless Chromium, executes each step, takes a screenshot after every action and records a Playwright trace.
The result page shows PASSED or FAILED status, step-by-step screenshots, duration and a Playwright Trace Viewer. If a notification channel is configured, Telegram or Slack receives an alert on failure.
Product gallery
WrightTest gives teams a web interface for creating browser checks, running them on demand or on a schedule, and debugging failures with screenshots and traces.
1 / 10
Features
Each feature is designed around a real workflow, including recording, environment management, scheduling and reporting.
The recording session streams a real browser window into an iframe. Works in Docker with a virtual display based on Xvfb, so there is no host display or browser installation needed.
Uses Playwright codegen locator strategy and prefers data-testid, aria-label, href and role-based selectors over nth-child CSS paths that break on layout changes.
Dedicated step types for toBeVisible, toHaveText, toHaveValue, toHaveURL, toHaveTitle, toBeChecked and toHaveCount.
Variables like {{BASE_URL}} and {{PASSWORD}} are defined per environment, such as Dev, Staging and Production, and substituted at runtime without editing the test.
Tests can target iPhone 15, Pixel 7, iPad Pro and other devices from Playwright built-in device list. Emulation covers viewport, user agent and touch capabilities.
Schedules run suites or individual tests on a cron expression. Each schedule has a run history page showing batched results per trigger with per-test status and error messages.
Tests can be grouped into suites and run as a batch from the UI, from a schedule or via the webhook endpoint. Useful for smoke tests and regression sets.
A single HTTP POST to /webhooks/trigger starts a test or suite. The endpoint accepts an optional HMAC signature and returns job IDs for polling.
Any test exports to a standard Playwright spec file. Variable values can be inlined from an environment, mapped to process.env, or left as placeholders.
Paste the contents of an existing Playwright .spec.ts file. The parser extracts goto, click, fill, press and assertion steps into the visual editor.
After each run the result page can open the Playwright Trace Viewer directly. Teams working with sensitive internal data should review trace contents before opening them through external viewer URLs.
Notification channels are configured per project. On FAILED status the channel receives the test name, duration and error message. Channels can be tested with a single click before use in production.
Comparison
WrightTest is not a replacement for writing Playwright tests in code. It is an interface layer that makes Playwright accessible to testers who do not work in a Node.js codebase daily.
| Feature | WrightTest | Selenium IDE | Cypress Studio | Playwright UI Mode |
|---|---|---|---|---|
| No-code visual recorder | ✓ via noVNC | ✓ | ✓ | — |
| Runs server-side in Docker | ✓ | — | — | — |
| Mobile device emulation | ✓ | — | partial | ✓ |
| Cron scheduler built in | ✓ | — | — | — |
| Environment variables in steps | ✓ | — | — | — |
| Export to native Playwright .spec.ts | ✓ | — | — | — |
| Webhook CI/CD trigger | ✓ | — | — | — |
| Playwright Trace Viewer | ✓ | — | — | ✓ |
| Self-hosted, no vendor lock-in | ✓ | ✓ | ✓ | ✓ |
| Telegram / Slack notifications | ✓ | — | — | — |
| Role-based locators (getByRole) | ✓ via codegen | — | depends on setup | ✓ |
For whom
The tool is designed for teams that need Playwright browser automation but do not want every test author to live inside a code editor all day.
Record flows quickly, add assertions, schedule regressions and review screenshots without waiting for a developer to write boilerplate.
Turn repetitive checks into reusable browser flows and export them as standard Playwright specs when it is time to move them into code.
Keep browser automation self-hosted and predictable, without buying a separate SaaS just to run and watch test sessions.
Limitations
WrightTest works best for straightforward browser interactions. Complex interactions like file uploads, drag-and-drop and canvas drawing may need to be added manually as steps after recording.
Tests that depend on dynamic content, such as real-time updates or unpredictable load times, may need waitForSelector steps added between actions to produce stable results.
WrightTest currently supports Chromium only. Firefox and WebKit support is on the roadmap.
Technical stack
The architecture uses no proprietary dependencies. Each component can be swapped or extended independently.
Practical Testing Guides
Explore lifecycle-based guides for forms, authentication, sessions and critical user journeys.
Latest guides: Shopping Cart Testing · Product Page Testing · Ecommerce Test Cases
View all testing guidesAuthentication Testing
Test the complete transition from claimed identity to protected access and safe termination.
Explore authentication testingWeb Form Testing
Move beyond visible field checks and prove the final business outcome of each form flow.
Explore web form testingFAQ
Common questions about the platform, usage and deployment.
WrightTest is a self-hosted web application for browser UI test automation built on Playwright. It provides a visual interface so testers can record, edit, run and schedule browser tests without writing TypeScript or JavaScript from scratch. For tests that go beyond what the recorder captures, steps can be edited manually or imported from an existing .spec.ts file.
Not for basic test creation. The recorder, step editor and assertions builder cover common flows without requiring Playwright knowledge. Understanding locators and Playwright's API becomes useful when debugging selector failures or editing complex steps manually.
Both tools offer a no-code recorder. WrightTest runs server-side inside Docker, uses Playwright's role-based locator strategy, includes a built-in scheduler, environment variable support, Telegram and Slack notifications, and exports tests as native Playwright .spec.ts files.
Yes, in two ways. The webhook endpoint accepts a project ID or test ID and queues the runs. Tests can also be exported as .spec.ts files and run with npx playwright test directly in the CI environment without WrightTest installed.
WrightTest supports mobile device emulation using Playwright's built-in device descriptors. Tests can target iPhone 15, Pixel 7, iPad Pro and other devices. Emulation covers viewport size, device pixel ratio, user-agent string and touch event simulation.
The Docker setup includes a dedicated novnc container running Xvfb, x11vnc and noVNC. When a recording session starts, the backend launches playwright codegen with DISPLAY=:99, which renders Chromium onto the virtual display. noVNC streams that display to the browser via WebSocket.
WrightTest is free for personal, educational, research and internal team use. The source code is available on GitHub. Commercial resale or offering WrightTest as a public hosted SaaS service requires prior written permission. Check the LICENSE file before using it in a commercial product or managed service.
Existing projects, tests and run history are stored in a PostgreSQL volume that persists across container restarts and rebuilds. On startup the backend runs prisma migrate deploy, which applies only new migrations without modifying existing data.
Yes. The import feature accepts the contents of a .spec.ts file via the project page. The parser extracts page.goto, click, fill, press, selectOption and assertion calls into the visual step editor.
Playwright traces are zip archives generated and stored on the WrightTest server. They contain DOM snapshots, network request logs, screenshots and console output from the test run. Teams working with sensitive internal systems should review what trace contents include before opening them through any external viewer URL.
WrightTest runs in Docker. No browser installation, no Node.js setup on the host, no cloud account required. Free for personal and internal team use.