Repository navigation
test(e2e): add Playwright + first 3 critical-path E2E scenarios - #9
Merged
Merged
Conversation
No E2E framework existed for the frontend before this — only Vitest unit tests under tests/useCases. Flagged as P0 in the QA/scalability plan.
Single chromium project for now; add more browsers once the first scenarios are stable. webServer auto-start is local-only — CI/staging runs assume the app is already deployed, per the phased plan (full staging E2E is a separate P1 item).
The submit button on LoginPage is disabled until recaptchaToken is set (frontend-side, independent of the backend's RECAPTCHA_REQUIRED flag), so login cannot be automated at all without either Google's official test key pair or a network-level mock of the recaptcha widget. Using the test key pair is Google's documented, supported way to do this and requires no code branching for "test mode" in the app itself.
… copy Avoids drift between test route constants and the actual app routes.
Covers the P0 "no E2E coverage at all" gap from the QA plan. Two cases: successful login reaching the dashboard, and invalid credentials surfacing an error without a false-positive redirect (the more dangerous failure mode for an auth flow).
Verifies the auth-gated /problems catalog loads and that opening a problem renders the core workspace (Run/Submit, tabs, Monaco editor mounted). Deliberately does NOT assert on Judge0 execution results yet — that needs seeded test problems/test-cases in a staging environment, tracked as a follow-up per the QA plan's phased full-stack E2E section.
Uses the "Details" button as the entry point since it's the one CourseCard action present regardless of price/access state. The full purchase flow (checkout → payment provider → entitlement granted → content unlocked) is intentionally left for a follow-up PR — it needs sandboxed Paymob/Kashier credentials and a seeded paid course, per the QA plan's payment E2E task (P0).
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
❌ Frontend CI Results
|
Vitest's default `include` glob matches any *.spec.js in the repo, so without an explicit `exclude` it was also picking up the new Playwright specs under tests/e2e/ and trying to run them with the wrong test runner API, failing the CI "Unit Tests" step (and, since that step isn't continue-on-error, blocking Build from running too).
✅ Frontend CI Results
|
This branch was successfully deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The frontend had zero E2E test coverage — only Vitest unit tests under
tests/useCases. Flagged as a P0 gap in the QA/scalability plan (AxeCode_QA_Scalability_Plan.md, section 2.4).What this adds
@playwright/test+ config (singlechromiumproject for now).tests/e2e/auth.spec.js— valid login → dashboard; invalid credentials → error shown, no false-positive redirect, form re-enabled.tests/e2e/problems.spec.js—/problemscatalog loads (auth-gated), opening a problem renders the workspace (Run/Submit buttons, tabs, Monaco editor mounted).tests/e2e/courses.spec.js—/coursescatalog loads (auth-gated), opening a course renders its details page.tests/e2e/utils/auth.js— shared login helper.tests/e2e/README.md— full setup instructions and explicit scope notes.A blocker worth flagging explicitly
LoginPage's submit button is disabled untilrecaptchaTokenis set — on the frontend itself, independent of the backend'sRECAPTCHA_REQUIREDflag. So no UI automation can log in at all without solving reCAPTCHA. The fix isn't a code change, it's environment config: Google publishes a test key pair specifically for this (documented intests/e2e/README.md), which verifies instantly with no real challenge. Requires settingVITE_RECAPTCHA_SITE_KEY(frontend) andRECAPTCHA_SECRET_KEY(backend) to the test values in whatever environment these tests run against — never in production.Deliberately out of scope for this PR (tracked as follow-ups, see QA plan)
Before merging
E2E_TEST_USER_EMAIL/E2E_TEST_USER_PASSWORDfor a seeded test account.npx playwright install --with-deps chromiumonce, thennpm run test:e2elocally to confirm all 3 specs pass end-to-end.