nebari-dev / nebari-dev/nebari-frames

Web e2e: add Playwright coverage for the Frame authoring and template flows

Open
#82 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

type: enhancement 💅🏼
Dominant language
Go
Stars
2
Forks
1
Avg merge
10h 55m
Merged PRs (30d)
9

Description

Motivation

The repo has no browser-level test harness. Web tests are vitest component and page
tests with a mocked Connect transport (web/src/**/*.test.tsx), and the e2e-sandbox
CI job verifies deployment and wiring - ArgoCD Synced/Healthy, real auth is on, the
gateway answers - but never drives the SPA.

That gap became concrete while specifying Frame templates (#60). Most of that
feature's definition-of-done is user-visible browser behaviour: the template picker
listing org and built-in templates, the authoring form landing pre-filled, a required
section's validation error appearing on that section rather than as a form-level
alert, and the admin template management page. None of it can be verified
automatically today, so those items are covered by vitest plus narrated manual
walkthroughs.

#60 adds authenticated RPC-level e2e tests against the deployed sandbox, which covers
the API surface. This issue is the browser half.

Proposal

  • Add Playwright, running against either make dev locally or the deployed sandbox in
    CI, reusing the authenticated-session work #60 introduces.
  • Cover the flows vitest cannot: the create-flow template picker, landing in a
    pre-filled authoring form, required-section error placement, admin template CRUD,
    and the existing ?import=1 .frame.md import path.
  • Decide whether it runs as a separate CI job or an extra stage of e2e-sandbox.
    A separate job keeps browser flake from failing the deployment smoke test.

Acceptance criteria

  • Playwright runs in CI against a real backend with real auth.
  • The Frame authoring and template flows above are covered.
  • Browser flake cannot fail the deployment verification in e2e-sandbox.
  • AGENTS.md documents how to run the suite locally.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reviewing the existing web/src/**/*.test.tsx tests, the e2e-sandbox job, and the authenticated-session work introduced by #60. Check how make dev and the deployed sandbox are used, then document the local workflow in AGENTS.md. Done means CI drives the listed Frame flows against a real backend and browser failures do not fail deployment verification.

Written by the indexing model from the issue text.

Assessment

Tech stack
playwright
Domain
ci-cd, frontend, testing-qa
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.