PrettyPlay

UI tests written as plain sentences. Each step sentence is turned into executable code once — by an LLM, against the live page — and cached in the repository. Every later run replays the cached code with no LLM involvement at all.

Install

pip install prettyplay
playwright install            # browser binaries for the driver

Requires Python 3.10+.

Quick start

from prettyplay import PrettyPlay


def test_login():
    t = PrettyPlay("login-flow")
    t.step("open the login page")
    t.step("enter the login and password")
    t.step("click the Sign in button")
    t.expect("the Welcome message appears")
    t.close()

Or with the context manager:

with PrettyPlay("login-flow") as t:
    t.step("open the login page")

Each PrettyPlay is fully self-contained: it owns its settings, its attempt budgets and its own browser session. close() (or leaving the with block) closes the page and stops the whole browser of that test.

What happens on a step

• cache hit — the cached code runs; no LLM is contacted
• cache miss — the step code is generated (a candidate that must actually work on the page), then cached; only successes are cached — after the compliance gate
• cached failure — the failure is classified:
  • rot (the UI changed) — the step is regenerated and the cache rewritten
  • fixable (the step code is at fault, the intent stays satisfiable) — regenerated for the same intent
  • product_defect — the test fails loudly; nothing is regenerated
  • incurable — the step fails with an explanation and a recommendation

A step inside a group block routes to the group recovery instead — one diagnosis of the whole group drives a group-scoped regeneration row (see Groups).

Strict replay-only mode (strict = true) never contacts the LLM for code: a cache miss fails immediately, a failed cached step is at most classified, and nothing is regenerated or healed. This is the natural CI posture: generate locally, run strict in the pipeline — see Configuration and Step cache.

Where to go next

• Getting started — wiring the library into a test framework or CI
• Writing steps — authoring tests as scenarios
• Configuration — pyproject.toml settings, env overrides, the PrettyConfig API
• Browser setup — engines, screen modes, remote browsers
• Failure taxonomy — the five failure kinds and the structured message
• Hooks and logging — event callbacks for custom reporting
• Step cache — addressing, storage, attempt budgets, CI workflow
• LLM providers — openai and anthropic parity, model settings
• Self-healing — classification categories and healing paths
• Groups — authoring blocks that heal as a unit
• Driver facade — the internal page handle, the worker boundary and the generated-code contour

!!! warning Step sentences land in the repository cache, the logs and the LLM requests: never put secrets or personal data into a step.