End-to-End Browser Testing
Relevant source files
The following files were used as context for generating this wiki page:
End-to-End (E2E) browser testing verifies the integrated behavior of the web application, API, and database. These tests use Playwright to simulate real user interactions across critical workflows, including staff invitations, sign-in, patient consultations, and appointment scheduling.
The testing suite operates against built versions of the apps/api and apps/web packages. It uses a dedicated, isolated database (E2E_DATABASE_URL) to ensure that test executions do not interfere with development or production data. Tests run in parallel, with each test case creating its own unique clinic organization and staff members directly in the database to maintain independence.
Sources: README.md:43-52, apps/e2e/playwright.config.ts:4-10
Test Infrastructure and Environment
The E2E environment consists of a separate API server and a Next.js web server. The global-setup.ts script ensures all applications are built and the database schema is current before tests begin.
Component Architecture
The diagram shows the relationship between the test runner, the application services, and the isolated database.
Sources: apps/e2e/playwright.config.ts:25-56, apps/e2e/global-setup.ts:7-22
Configuration Details
The system configures the test environment using the following parameters:
| Parameter | Value / Source | Description |
|---|---|---|
API_URL | http://localhost:4300/v1 | Base URL for the API service. |
WEB_URL | http://localhost:3300 | Base URL for the Next.js web application. |
DATABASE_URL | process.env.E2E_DATABASE_URL | Dedicated database for browser tests. |
JWT_SECRET | e2e-only-jwt-secret-... | Static secret used for token signing in tests. |
OTP_DELIVERY | disabled | Prevents actual OTP sending during E2E runs. |
Sources: apps/e2e/playwright.config.ts:11-50
Test Fixtures and Data Seeding
The suite utilizes Playwright fixtures to automate the creation of a fresh clinic for every test. This includes generating an organization, staff roles (Admin, Doctor, Front Desk), and synthetic patients.
Data Setup Flow
This flow illustrates how the clinic fixture populates the database with necessary entities before the test script executes.
Sources: apps/e2e/fixtures.ts:22-63
The Clinic Object
The Clinic interface provides methods to retrieve role-specific credentials and invite links for use within tests:
slug: Unique identifier for the clinic.inviteLink(role): Generates a URL containing the Base64URL encoded invite token.email(role): Returns the generated test email for a specific role.
Sources: apps/e2e/fixtures.ts:10-20
Authentication and Security Testing
Tests verify the security of staff sessions, including password setup, Multi-Factor Authentication (MFA), and session persistence.
Staff Invitation and MFA Setup
The setUpFromInvite function automates the initial onboarding flow. It navigates to an invite link, sets a password, retrieves the TOTP secret from the UI (specifically from a data-testid="manual-key" element), and calculates a valid 6-digit code to complete setup.
Sources: apps/e2e/fixtures.ts:89-101
Session Management
The system uses an httpOnly cookie named dhc_session for session tracking. Tests verify that:
- The cookie is not accessible via
document.cookiein client-side scripts. - Sessions persist across page reloads.
- Sessions are invalidated after 15 minutes of inactivity using Playwright's clock manipulation.
Sources: apps/e2e/tests/signin.spec.ts:10-24, apps/e2e/tests/signin.spec.ts:57-70
Clinical and Operational Workflows
The E2E suite covers the primary business logic of the healthcare platform, ensuring data flows correctly from the front desk to the doctor.
Consultation Flow
- Vitals Recording: Front desk staff can record patient vitals (weight, height, BP), but are restricted from accessing clinical notes.
- Clinical Documentation: Doctors record chief complaints, symptoms, and ICD-10 diagnoses.
- Autosave: The UI must display a "Saved" status as the doctor enters information.
- Data Integrity: Information must remain available and correct after a page reload.
Sources: apps/e2e/tests/consultation.spec.ts:55-104, apps/e2e/tests/consultation.spec.ts:117-133
Appointment Lifecycle
The suite tests the transition of appointments through various states:
- Booking: Selecting slots from the doctor's availability.
- Checking In: Transitioning a booked appointment or walk-in to the active queue.
- Consultation: Moving from "In consultation" to "Completed".
- Rescheduling/Cancellation: Moving appointments to the "Cancelled and no-shows" tab with a required reason.
Sources: apps/e2e/tests/appointments.spec.ts:60-120, apps/e2e/tests/appointments.spec.ts:168-185
Waiting-Room Screen
Tests verify the privacy-preserving "Display Board" which shows token numbers to patients. The system ensures that:
- Clinic admins can create and revoke screen links.
- The display board shows the current serving token and upcoming tokens.
- No patient names are rendered on the public display board.
Sources: apps/e2e/tests/queue.spec.ts:79-114
Summary
End-to-End Browser Testing in this project provides a robust safety net by simulating complete user journeys on a production-like build. By utilizing isolated databases, automated data seeding via fixtures, and precise session monitoring, the suite ensures that critical healthcare operations—from staff onboarding to patient consultations—remain functional and secure.