Skip to content

[2026-01-21] Guest Mode: QA & Testing

Task Metadata

  • 📆 Date: 2026-01-21
  • 🚥 Status: Complete

Objective

Goal: validate the end-to-end functionality of Guest Mode using Playwright (Layer 4 Integration Tests).

  • Trigger: Frontend implementation of Guest Mode services is complete. We need to ensure the UI actually works for unauthenticated users.
  • Constraints:
    • Must run in CI.
    • Must verify data persistence across reloads (testing IndexedDB).
    • Must verify that no network calls are made to the API for guest actions.

Technical Strategy

We will create a new Playwright test suite guest-mode.spec.ts that specifically targets the unauthenticated experience.

  • Key Decisions:
    • Unlock UI: Permanently enable the Dashboard for unauthenticated users in Tracker.tsx. This effectively launches Guest Mode.
    • Guest UI Adjustments: Modify Dashboard, Header, and SettingsModal to gracefully handle user=null (e.g., hide "Sign Out", show "Sign In", hide "Account" settings).
    • Network Interception: Use Playwright's page.route or request monitoring to assert that POST /graphql is NOT called when adding a meal in Guest Mode.

Testing Strategy

  • Must Test:
  • Load: Page loads without redirecting to Login.
  • Guest UI: Header shows "Guest" or "Sign In" instead of Email.
  • Action: Add Meal adds item to list.
  • Persistence (Meals): Meal remains after reload.
  • Persistence (Settings): Modified calorie target remains after reload.
  • Isolation: No API calls during Add Meal or Update Settings.
  • Upgrade Path: Clicking "Sign In" redirects to login/authenticator.
  • Skip: Sync/Import flows (Backend not yet connected to UI).

Risk Analysis

  • UI Exposure: Enabling the Dashboard for guests exposes features that traditionally assume a user exists.
  • Impacted Features:
  • Header: Currently shows "Sign Out" for all. Needs to show "Sign In" or "Log In" for guests to allow "upgrading" their account.
  • Auth Session: Dashboard.tsx attempts to fetch a session to get federated emails. This must be skipped for guests to avoid console errors/failed promises.
  • Auth Guard: The primary gate in Tracker.tsx must be permanently removed to allow /track to resolve for guests.
  • Documentation: This validates Decision 006: Guest Mode Architecture.
  • Files to Modify:
    • frontend/src/pages/Tracker.tsx (Enable Guest Access)
    • frontend/src/pages/Dashboard.tsx (Handle null user & conditional session fetch)
    • frontend/src/components/Header.tsx (Guest state UI & Sign In button)
    • frontend/tests/guest-mode.spec.js (New E2E Test)
    • docs/architecture/testing_strategy.md (Update with Layer 4 specifics)

Critique & Gaps

  • Critique 1 (Null Object Pattern vs Spaghetti): Passing user={null} down the component tree invites runtime crashes (Cannot read property of null). Instead of sprinkling if (user) everywhere, consider creating a GUEST_USER constant that satisfies the User interface but has isGuest: true. This simplifies the UI logic significantly.
  • Critique 2 (The 'Log Out' Trap): If a user explicitly signs out, they are immediately dropped into Guest Mode. If the previous Guest Data wasn't cleared upon login (sync), they might see old data. If it was cleared, they see a blank slate. We need to define this behavior. Recommendation: Explicit Sign Out should probably clear the Guest DB to prevent data leaking between users on shared devices.
  • Critique 3 (Security by Obscurity): "Hiding" the Account settings button isn't enough. Ensure the SettingsModal logic doesn't crash or attempt API calls if force-opened in Guest Mode.
  • Critique 4 (Test Coverage): The test plan verifies "Happy Path" (add/persist). It misses the "Sad Path": What happens if a Guest tries to access a protected route directly? Or uses a feature that requires cloud processing (like Image Analysis, if we had it)?

Gap Analysis

  • Gap: How do we distinguish a "Guest" from a "Logged Out" user who should log in?
  • Answer: For now, the /track route will default to Guest Mode if no session. The "Login" button in the Header allows upgrading.

Execution Notes

  • Testing: Created frontend/tests/guest-mode.spec.js which verifies UI rendering, IndexedDB persistence, and network isolation.
  • Fixes: Updated Playwright tests to handle clipboard permissions and button text ("Confirm Meal") correctly.
  • Documentation: Uplifted docs/architecture/testing_strategy.md to reflect the final implementation of Layer 4.

User Approval & Key Learnings

Key Learnings

  • Playwright's page.route is effective for asserting network isolation in Guest Mode.
  • Testing IndexedDB requires careful handling of page reloads to ensure data persistence is verified.

(User to confirm approval and add notes/learnings)

Context Memory (AI-Only)

Summary for Future Context

Implemented Layer 4 Playwright tests for Guest Mode, verifying end-to-end functionality without backend dependency.