Skip to content

[PLAN] Automated Playwright and Screenshot Flow #38

Description

@L03TJ3

[PLAN] Automated Playwright and Screenshot Flow

Required states, flows, and behaviors

  • Establish a deterministic browser-test mode that starts GoodWallet without production credentials, real funds, or uncontrolled third-party/network state.
  • Cover a small, stable initial journey set: locale-aware login/onboarding entry, an authenticated wallet home state with representative balances and the app-action overflow behavior, and the GoodDollar claim UI. use a newly generated wallet in tests and should for claim UI show that it needs Verification.
  • Exercise desktop and mobile viewports in Chromium for the initial increment; retain cross-browser expansion and broad visual-diff coverage as follow-on work.
  • Capture named PNG checkpoints for each approved flow and viewport. Keep per-run screenshots, traces, videos, and logs as CI artifacts; use committed baselines only for explicitly approved stable visual checkpoints. all screenshots for main flow should be placed in root level directory 'tests-playwright//screenshot-state-1.png <-- whatever the state is
  • Use semantic, user-facing locators and wait for deterministic UI readiness. Stub authentication, RPC/wallet, GoodDollar, analytics, and other external integrations at the browser boundary so the suite never creates transactions or accesses real accounts.

Execution plan

  1. Confirm the initial journeys, fixture data, visual approval ownership, retention period, and CI triggering policy with product and engineering.
    First flows is just main screen and claim ubi flow.

  2. Add Playwright and its browser/runtime setup using the Yarn workspace, with commands for local browser-test execution and screenshot generation; pin behavior through the existing lockfile.

  3. Add a Playwright configuration and dedicated test bootstrap that runs the Next.js app in a test environment, applies fixed locale/timezone/viewport settings, and writes results to a gitignored artifact directory.

  4. Implement reusable browser fixtures and route-level mocks for identity, wallet/RPC responses, GoodDollar claim state, analytics, and all selected remote APIs. Supply static test accounts and token data only; prohibit live transactions and external credentials.

  5. Add the approved initial browser flows, semantic locators, readiness assertions, and consistently named screenshot checkpoints. Add only the product-approved baseline images; retain all other captures as run artifacts.

  6. publishing screenshots is only triggered through agents per pull-request, not currently run automatic on all pull-requests. plus Playwright traces/videos/logs on failure and selected screenshots on success. Keep the existing Biome, build, and Vitest checks intact.

  7. Document prerequisites, local commands, fixture/mock boundaries, artifact locations, adding a flow, approving intentional baseline updates, and failure triage. Record the agreed browser/viewport support and follow-on visual-regression scope.

Reference files and packages

  • /home/runner/work/GoodWallet/GoodWallet/package.json — Yarn 4 scripts, Next.js/Vitest toolchain, and existing @gooddollar/goodprotocol dependency to reuse rather than duplicate GoodDollar protocol behavior.
  • /home/runner/work/GoodWallet/GoodWallet/yarn.lock — dependency lockfile to update when Playwright is introduced.
  • /home/runner/work/GoodWallet/GoodWallet/.github/workflows/goodwallet-pr.yml — existing main/PR build workflow where browser coverage and artifacts should be integrated.
  • /home/runner/work/GoodWallet/GoodWallet/README.md — local setup and command documentation to extend.
  • /home/runner/work/GoodWallet/GoodWallet/src/app/[locale]/@login/(login)/page.tsx and /home/runner/work/GoodWallet/GoodWallet/src/sections/Login/LoginView.tsx — login journey entry points.
  • /home/runner/work/GoodWallet/GoodWallet/src/app/[locale]/@home/(home)/layout.tsx, /home/runner/work/GoodWallet/GoodWallet/src/sections/Home/HomeView.tsx, and /home/runner/work/GoodWallet/GoodWallet/src/sections/Home/components/WalletSection.tsx — authenticated-home and overflow-action journey references.
  • /home/runner/work/GoodWallet/GoodWallet/src/sections/GoodDollar/GoodDollarView.tsx and /home/runner/work/GoodWallet/GoodWallet/src/sections/GoodDollar/components/Claim/ — GoodDollar claim-state journey references.
  • /home/runner/work/GoodWallet/GoodWallet/src/ethers-utils/utils.test.ts — existing Vitest module-mocking conventions to adapt at the browser boundary.

No other repositories are mentioned by the parent issue. Reuse the existing @gooddollar/goodprotocol package; do not introduce replacement GoodDollar protocol packages.

Acceptance criteria

  • A documented Yarn command runs the selected browser flows locally and produces predictable screenshots without real user secrets, funds, accounts, or live transactions.
  • The initial agreed flows run deterministically in Chromium at documented desktop and mobile viewports, with stable fixture data and mocked integration boundaries.
  • Screenshot checkpoint names and locations are documented; approved baselines are limited to intentional stable checkpoints, while execution artifacts remain available from CI.
  • Pull requests run the browser check under the agreed trigger policy without removing or weakening Biome, build, or Vitest checks.
  • CI uploads screenshots and failure diagnostics (trace, video, and logs where available) using the agreed retention period.
  • Documentation explains setup, execution, artifacts, adding flows, approving baseline changes, and diagnosing failures.

Human-reviewer checklist

  • Product confirms the initial journeys, exact screenshot checkpoints, and visual approval owner.
  • Engineering approves mocked boundaries, deterministic fixture data, and the guarantee that no live wallet/claim/transaction interaction is possible.
  • QA approves Chromium plus the chosen desktop/mobile viewport coverage and the deferral of cross-browser and broad visual-diff testing.
  • Maintainers approve PR trigger conditions, runtime budget, artifact retention, and CI storage cost.
  • Security review confirms test configuration and artifacts cannot expose credentials, private keys, session data, or production user data.
  • Documentation and baseline-update ownership are accepted before enabling the required PR check.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions