New Playwright test for Manage CARE Team #15073
Conversation
Deploying care-preview with
|
| Latest commit: |
93b6e31
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://d630252c.care-preview-a7w.pages.dev |
| Branch Preview URL: | https://careteam-link-test.care-preview-a7w.pages.dev |
WalkthroughAdds a Playwright test suite for managing care teams on patient encounters, exercising the Manage Care Team dialog: opening, member+role selection, add/validation flows, duplicate-prevention, UI state checks, and cleanup after tests. Changes
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
🧪 Generate unit tests (beta)
Comment |
There was a problem hiding this comment.
Pull request overview
This PR adds comprehensive end-to-end tests for the Manage Care Team functionality, along with numerous bug fixes and feature improvements across the healthcare application. The test suite validates the complete workflow of adding, preventing duplicates, and managing care team members within patient encounters.
Key Changes
- Added new Playwright test file to cover the "Manage Care Team" feature in patient encounters
- Test suite covers member addition, duplicate prevention, button state management, and form persistence
- Tests use the authenticated user state and verify all critical user interactions with the care team dialog
| test.describe("Manage care team for an encounter", () => { | ||
| let facilityId: string; | ||
| let selectedRole: string; | ||
|
|
||
| const username = "care-fac-admin"; |
There was a problem hiding this comment.
The constant name username is ambiguous as it represents a specific test user. Consider renaming to TEST_USERNAME or careAdminUsername to clarify this is a hardcoded test fixture value.
| test.describe("Manage care team for an encounter", () => { | |
| let facilityId: string; | |
| let selectedRole: string; | |
| const username = "care-fac-admin"; | |
| test.describe("Manage care team for an encounter", () => { | |
| let facilityId: string; | |
| let selectedRole: string; | |
| const careAdminUsername = "care-fac-admin"; |
| const roles = [ | ||
| "Primary healthcare service", | ||
| "Acupuncturist", | ||
| "Orthotist and prosthetist", | ||
| ]; |
There was a problem hiding this comment.
The constant name roles is generic. Consider renaming to TEST_ROLES or availableTestRoles to indicate these are test fixture values for role selection.
| try { | ||
| const dialog = page.getByRole("dialog", { name: "Manage Care Team" }); | ||
| const removeButton = dialog | ||
| .locator("button") | ||
| .filter({ has: page.locator("svg.lucide-x") }) | ||
| .last(); | ||
| await removeButton.click(); | ||
| await page.getByRole("button", { name: "Remove" }).click(); | ||
| await expectToast(page, /removed successfully/i); | ||
| } catch { | ||
| // Member might already be removed or not added | ||
| } |
There was a problem hiding this comment.
The cleanup logic silently catches all errors without verification. While the comment explains the intent, this could mask actual test failures. Consider verifying the dialog is still visible before attempting cleanup, or at minimum check if the specific element exists before interacting with it to make the cleanup more robust.
| try { | |
| const dialog = page.getByRole("dialog", { name: "Manage Care Team" }); | |
| const removeButton = dialog | |
| .locator("button") | |
| .filter({ has: page.locator("svg.lucide-x") }) | |
| .last(); | |
| await removeButton.click(); | |
| await page.getByRole("button", { name: "Remove" }).click(); | |
| await expectToast(page, /removed successfully/i); | |
| } catch { | |
| // Member might already be removed or not added | |
| } | |
| const dialog = page.getByRole("dialog", { name: "Manage Care Team" }); | |
| // If the dialog is not visible (or cannot be queried), there is nothing to clean up. | |
| const isDialogVisible = await dialog.isVisible().catch(() => false); | |
| if (!isDialogVisible) { | |
| return; | |
| } | |
| const removableMembers = dialog | |
| .locator("button") | |
| .filter({ has: page.locator("svg.lucide-x") }); | |
| const removableCount = await removableMembers.count(); | |
| // No removable members found; nothing to clean up. | |
| if (removableCount === 0) { | |
| return; | |
| } | |
| const removeButton = removableMembers.last(); | |
| await removeButton.click(); | |
| await page.getByRole("button", { name: "Remove" }).click(); | |
| await expectToast(page, /removed successfully/i); |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 7
🤖 Fix all issues with AI agents
In @tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts:
- Around line 9-15: Modify openCareTeamDialog to return the dialog locator for
the "Manage Care Team" dialog (e.g., the result of page.getByRole("dialog", {
name: "Manage Care Team" })) and update callers to use that returned locator for
all subsequent queries and assertions (scope calls like getByRole, getByText,
etc. using dialog.locator(...) or dialog.getByRole(...)) so every interaction is
constrained to the dialog and avoids matching other page elements; keep the
existing clicks in openCareTeamDialog (tab and button) but return the dialog
locator instead of only asserting visibility.
- Around line 157-196: Replace the fragile visibility assertions in the "Closing
without clicking Add does not save care team member" test: instead of using
dialog.getByText(username).not.toBeVisible() and
dialog.getByText(selectedRole).not.toBeVisible(), assert the elements do not
exist by using dialog.getByText(username).toHaveCount(0) and
dialog.getByText(selectedRole).toHaveCount(0); keep the same scoped dialog
locator and the openCareTeamDialog flow so the checks remain within the Manage
Care Team dialog.
- Around line 99-141: After the duplicate-add step in the "Cannot add same
member with same role twice" test (after the expectToast call), add an assertion
that the care team UI contains only one entry for the given
username/selectedRole pair: locate the care-team rows/entries that include
username and selectedRole (reusing the same selectors used earlier after
openCareTeamDialog) and assert their count is exactly 1 so the UI state wasn’t
duplicated; keep this check immediately after the duplicate-add expectToast and
reference the test, openCareTeamDialog, username, and selectedRole identifiers.
- Around line 57-97: Move the dialog lookup to the start of the test (inside
test("Add a care team member with role" ...)) by creating const dialog =
page.getByRole("dialog", { name: "Manage Care Team" }); immediately after
opening the care team sheet, then replace all unscoped page.* selectors with
dialog.* (e.g., dialog.getByRole("combobox").filter(...),
dialog.getByText(...)). Remove placeholder-based selectors: for selecting the
member use dialog.getByRole("option", { name: username }) (instead of
getByPlaceholder("Search").fill and clicking by text), and for selecting the
role use dialog.getByRole("option", { name: selectedRole }) (instead of
getByPlaceholder("Select Role").fill); keep the final verification using
dialog.getByText(selectedRole).
- Around line 144-155: The test currently uses page.getByRole("button", { name:
"Add" }) which may match other "Add" buttons; change the assertion to scope it
to the Manage Care Team dialog by locating the dialog (use
page.getByRole("dialog", { name: "Manage Care Team" }) and store it, e.g., const
dialog) and then assert on dialog.getByRole("button", { name: "Add" }) in the
"Verify Add button is disabled" step (this ensures the assertion targets the
care team sheet opened by openCareTeamDialog).
- Around line 40-55: The cleanup blindly uses .last() on the remove button and
can delete the wrong member; update the test.afterEach cleanup to locate the
specific care-team row that contains the added member by matching the displayed
member name (use formatName(member.member) or the username visible text)
together with the rendered role text (member.role.display or
selectedRole.display), then find that row's remove button (instead of using
.last()) and click it; if DOM text matching is flaky, add and use a stable
data-testid on the remove button for that member and target it (references:
dialog locator, removeButton, .last(), formatName, member.role.display,
username).
📜 Review details
Configuration used: Repository UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (1)
tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts
🧰 Additional context used
📓 Path-based instructions (7)
**/*.{ts,tsx}
📄 CodeRabbit inference engine (.cursorrules)
**/*.{ts,tsx}: Write concise, technical TypeScript code with accurate examples
Use TypeScript for all code; prefer interfaces over types
Avoid enums; use maps instead
Use TanStack Query for data fetching from the API along with query and mutate utilities for the queryFn and mutationFn
Use raviger for routing
**/*.{ts,tsx}: Use TypeScript with strict mode and ES2022 target
Useinterfacefor defining object types in TypeScript
Avoid explicitanytype in TypeScript
Use proper nullability annotations in TypeScript types
Use dedicated error handlers and TypeScript strict null checks
**/*.{ts,tsx}: Use TypeScript for all new code
Prefer interfaces over types for object definitions in TypeScript
Avoid usinganytype; use proper type definitions in TypeScript
Use type inference where possible in TypeScript
Use TanStack Query for API data management
Prefer React Context for global state management
**/*.{ts,tsx}: Use TanStack Query with thequeryandmutateutilities from@/Utils/request/
Use appropriate query keys following the resource pattern for TanStack Query
Leverage TanStack Query built-in features for pagination and debouncing
Implement proper error handling using the global error handler for TanStack Query operations
UseuseQueryhook withqueryKeyandqueryFnparameters, wherequeryFnwraps the API route with thequery()utility
UseuseMutationhook withmutationFnparameter wrapping API routes with themutate()utility, and implementonSuccesscallbacks to invalidate related queries
Support path parameters in TanStack Query using thepathParamsoption in query/mutate utilities
Support query parameters in TanStack Query using thequeryParamsoption in query/mutate utilities
Use thesilent: trueoption to suppress global error notifications when custom error handling is needed
**/*.{ts,tsx}: Use TypeScript with strict mode and ES2022 target
Useinterfacefor defining object types
Avoid explicitanytypes and maint...
Files:
tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts
**/*.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (.cursorrules)
**/*.{ts,tsx,js,jsx}: Use functional and declarative programming patterns; avoid classes
Prefer iteration and modularization over code duplication
Use descriptive variable names with auxiliary verbs (e.g., isLoading, hasError)
Use the "function" keyword for pure functions
Avoid unnecessary curly braces in conditionals; use concise syntax for simple statements
**/*.{ts,tsx,js,jsx}: Use path aliases for imports from src (@/*)
Use double quotes for strings
Semicolons are required at end of statements
Order imports as: 3rd-party → library → CAREUI → UI → components → hooks → utils → relative
Use PascalCase for component and class names
Use camelCase for variable and function names
**/*.{ts,tsx,js,jsx}: Use path aliases@/*for imports from src directory
Use double quotes for strings
Require semicolons at end of statements
Order imports: 3rd-party → library → CAREUI → UI → components → hooks → utils → relative
Use PascalCase for component and class names
Use camelCase for variable and function names
Files:
tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts
**/*
📄 CodeRabbit inference engine (CLAUDE.md)
Use 2-space indentation
Files:
tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts
**/*.ts
📄 CodeRabbit inference engine (.cursor/rules/02-coding-standards.mdc)
Use camelCase for utility file names (e.g.,
useAuth.ts)
Files:
tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts
**/*.spec.ts
📄 CodeRabbit inference engine (.cursor/rules/02-coding-standards.mdc)
**/*.spec.ts: Write E2E tests in Playwright following https://playwright.dev/docs/writing-tests
Write meaningful test descriptions
Files:
tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts
**/*.{tsx,ts}
📄 CodeRabbit inference engine (.cursor/rules/04-ui-components.mdc)
**/*.{tsx,ts}: Use Shadcn UI components as the primary component library
Follow the component documentation for proper usage
Customize components using Tailwind CSS
UsenavigateanduseRedirectfrom raviger for navigation and redirects
Use Tailwind's responsive classes and follow mobile-first approach
Implement proper ARIA attributes for accessibility
Ensure keyboard navigation works in components
Define component props using TypeScript interfaces
Use translation keys fromsrc/Locale/for internationalization
Support RTL languages in components
Use proper date/time formatting for multiple language support
Files:
tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts
**/*.{ts,tsx,js,jsx,json,css,scss,html}
📄 CodeRabbit inference engine (AGENTS.md)
Use 2-space indentation
Files:
tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts
🧠 Learnings (14)
📓 Common learnings
Learnt from: CR
Repo: ohcnetwork/care_fe PR: 0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-11-25T13:50:10.786Z
Learning: Playwright E2E tests required for critical healthcare workflows and must be run before deployment
Learnt from: CR
Repo: ohcnetwork/care_fe PR: 0
File: .github/instructions/careui.instructions.md:0-0
Timestamp: 2025-11-25T13:50:46.407Z
Learning: Applies to src/CAREUI/**/*.{test,spec}.{ts,tsx} : Implement comprehensive testing in CAREUI components including accessibility and medical workflow scenarios
Learnt from: CR
Repo: ohcnetwork/care_fe PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-25T13:53:49.727Z
Learning: Run Playwright tests with `npm run playwright:test` for headless mode or `npm run playwright:test:ui` for interactive mode
Learnt from: CR
Repo: ohcnetwork/care_fe PR: 0
File: .cursor/rules/02-coding-standards.mdc:0-0
Timestamp: 2025-11-25T13:54:09.978Z
Learning: Applies to **/*.spec.ts : Write E2E tests in Playwright following https://playwright.dev/docs/writing-tests
Learnt from: CR
Repo: ohcnetwork/care_fe PR: 0
File: .github/instructions/config-files.instructions.md:0-0
Timestamp: 2025-11-25T13:51:07.680Z
Learning: Applies to playwright.config.ts : Maintain `playwright.config.ts` as the Playwright testing configuration
📚 Learning: 2025-11-25T13:50:46.407Z
Learnt from: CR
Repo: ohcnetwork/care_fe PR: 0
File: .github/instructions/careui.instructions.md:0-0
Timestamp: 2025-11-25T13:50:46.407Z
Learning: Applies to src/CAREUI/**/*.{test,spec}.{ts,tsx} : Implement comprehensive testing in CAREUI components including accessibility and medical workflow scenarios
Applied to files:
tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts
📚 Learning: 2026-01-02T12:19:24.476Z
Learnt from: SiddanthNayak
Repo: ohcnetwork/care_fe PR: 14906
File: tests/facility/overview/overview.spec.ts:6-39
Timestamp: 2026-01-02T12:19:24.476Z
Learning: In facility tests (e.g., tests/facility/overview/overview.spec.ts and similar), URL assertions may include dynamic filters/query parameters. Use .toContain() (or similar contains-based checks) instead of exact URL matches (like toHaveURL or strict equality) to accommodate runtime-added query parameters. Apply this approach to all relevant facility-spec.ts files.
Applied to files:
tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts
📚 Learning: 2024-11-18T10:48:08.500Z
Learnt from: Jacobjeevan
Repo: ohcnetwork/care_fe PR: 9145
File: cypress/e2e/patient_spec/PatientConsultationCreation.cy.ts:93-94
Timestamp: 2024-11-18T10:48:08.500Z
Learning: In `cypress/e2e/patient_spec/PatientConsultationCreation.cy.ts`, bed capacity verification assertions after patient admission are already being performed elsewhere, so adding them here is unnecessary.
Applied to files:
tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts
📚 Learning: 2024-12-04T18:58:47.241Z
Learnt from: kihan2518B
Repo: ohcnetwork/care_fe PR: 8956
File: cypress/e2e/facility_spec/FacilityCreation.cy.ts:261-261
Timestamp: 2024-12-04T18:58:47.241Z
Learning: In `cypress/e2e/facility_spec/FacilityCreation.cy.ts`, the test case titled "Create a new facility with no bed and doctor capacity" includes steps to select bed types and specializations before validation. This is done intentionally to verify that error messages are shown properly when no capacity is specified.
Applied to files:
tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts
📚 Learning: 2025-11-25T13:54:09.978Z
Learnt from: CR
Repo: ohcnetwork/care_fe PR: 0
File: .cursor/rules/02-coding-standards.mdc:0-0
Timestamp: 2025-11-25T13:54:09.978Z
Learning: Applies to **/*.spec.ts : Write E2E tests in Playwright following https://playwright.dev/docs/writing-tests
Applied to files:
tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts
📚 Learning: 2024-11-18T10:46:56.270Z
Learnt from: Jacobjeevan
Repo: ohcnetwork/care_fe PR: 9145
File: cypress/e2e/facility_spec/FacilityHomepage.cy.ts:229-317
Timestamp: 2024-11-18T10:46:56.270Z
Learning: In `cypress/e2e/facility_spec/FacilityHomepage.cy.ts`, when verifying the bed capacity badge reflection, the badge remains the same during multiple actions and only updates after a bed is attached to a patient during consultation. Therefore, it's appropriate to keep the test case consolidated rather than splitting it into smaller tests.
Applied to files:
tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts
📚 Learning: 2025-11-25T13:50:46.407Z
Learnt from: CR
Repo: ohcnetwork/care_fe PR: 0
File: .github/instructions/careui.instructions.md:0-0
Timestamp: 2025-11-25T13:50:46.407Z
Learning: Applies to src/CAREUI/**/*.{ts,tsx} : Use standard medical component interface patterns with medicalContext, accessibility properties (ariaLabel, screenReaderText), clinical validation callbacks (onValidationError), and medical data properties (patientId, facilityId)
Applied to files:
tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts
📚 Learning: 2025-11-20T09:48:26.486Z
Learnt from: yash-learner
Repo: ohcnetwork/care_fe PR: 14108
File: tests/facility/settings/activityDefinitions/activityDefinitionCreate.spec.ts:86-147
Timestamp: 2025-11-20T09:48:26.486Z
Learning: In tests/facility/settings/activityDefinitions/activityDefinitionCreate.spec.ts, detailed verification of selected values (e.g., code from value sets) in the detail view is intentionally deferred to the list spec, as the creation test focuses on the happy path and basic verification only.
Applied to files:
tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts
📚 Learning: 2024-11-18T10:44:30.303Z
Learnt from: Jacobjeevan
Repo: ohcnetwork/care_fe PR: 9145
File: cypress/e2e/facility_spec/FacilityCreation.cy.ts:177-180
Timestamp: 2024-11-18T10:44:30.303Z
Learning: In `cypress/e2e/facility_spec/FacilityCreation.cy.ts`, when testing bed and staff capacity individually for additional error verification, we prefer to use separate method calls to handle bed and staff capacity, rather than using `facilityPage.createNewFacility(testFacilityData)` which also handles bed management.
Applied to files:
tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts
📚 Learning: 2025-01-09T05:37:17.120Z
Learnt from: nihal467
Repo: ohcnetwork/care_fe PR: 9846
File: cypress/pageObject/facility/FacilityCreation.ts:14-47
Timestamp: 2025-01-09T05:37:17.120Z
Learning: In the care_fe project's Cypress tests, facility test data is managed through the facilityData.ts utility which provides pre-validated data through the FacilityTestData interface, making additional validation in the FacilityCreation page object unnecessary.
Applied to files:
tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts
📚 Learning: 2024-11-14T10:28:32.680Z
Learnt from: Jacobjeevan
Repo: ohcnetwork/care_fe PR: 9080
File: cypress/pageobject/Users/ManageUserPage.ts:181-188
Timestamp: 2024-11-14T10:28:32.680Z
Learning: In the Cypress tests for user management (`cypress/pageobject/Users/ManageUserPage.ts`), the method `verifyDoctorQualification()` is intended to verify qualifications specifically for the Doctor role.
Applied to files:
tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts
📚 Learning: 2025-11-25T13:51:23.408Z
Learnt from: CR
Repo: ohcnetwork/care_fe PR: 0
File: .github/instructions/context.instructions.md:0-0
Timestamp: 2025-11-25T13:51:23.408Z
Learning: Applies to src/context/**/*.{test,spec}.{ts,tsx} : Test role-based access control in context implementations
Applied to files:
tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts
📚 Learning: 2026-01-02T18:04:26.656Z
Learnt from: shiv7shukla
Repo: ohcnetwork/care_fe PR: 14986
File: tests/organization/patient/searchpatient/keyboardNavigation.spec.ts:8-8
Timestamp: 2026-01-02T18:04:26.656Z
Learning: In Playwright tests (e.g., tests/organization/patient/searchpatient/keyboardNavigation.spec.ts), when simulating keyboard shortcuts that could trigger the browser's search (Ctrl+K), use a lowercase 'k' (e.g., 'Control+k') to prevent the browser search bar from opening. This ensures test interactions are not disrupted. Apply this guideline to all Playwright test files that simulate shortcuts.
Applied to files:
tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts
🧬 Code graph analysis (1)
tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts (2)
tests/support/facilityId.ts (1)
getFacilityId(12-43)tests/helper/ui.ts (1)
expectToast(426-433)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (4)
- GitHub Check: build
- GitHub Check: Test
- GitHub Check: CodeQL-Build
- GitHub Check: Cloudflare Pages: care-preview
🔇 Additional comments (1)
tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts (1)
1-8: Consider deterministic test data for better stability, and strengthen cleanup targeting to avoid deleting wrong member.Using
faker.helpers.arrayElement(roles)per test introduces randomness where it's not necessary. The project's established pattern prefers deterministic selections when dealing with stable backend data (as shown in similar facility tests). Since the roles array is static, use a fixed role likeroles[0]for repeatability.Additionally, the cleanup logic at line 47 uses
.last()to target the remove button, which is fragile if multiple care team members exist. Instead, identify the specific member by username and role before removing to ensure you're deleting the correct entry. Guard the cleanup with a check to avoid errors if the member was already removed.English placeholders like
"Search"and"Select Role"are used consistently across facility tests, but be aware this will fail in non-English locales if multi-language testing is in scope.Since
playwright.config.tshasfullyParallel: true, verify that the encounter data is properly isolated per test run to prevent parallel execution conflicts.⛔ Skipped due to learnings
Learnt from: SiddanthNayak Repo: ohcnetwork/care_fe PR: 14906 File: tests/facility/overview/overview.spec.ts:6-39 Timestamp: 2026-01-02T12:19:39.931Z Learning: In tests/facility/overview/overview.spec.ts (and likely other facility tests), the appointments and encounters pages dynamically add extra filters or query parameters to the URL, so URL assertions should use `.toContain()` rather than exact matches with `.toHaveURL()` to accommodate these dynamic additions.Learnt from: CR Repo: ohcnetwork/care_fe PR: 0 File: .github/instructions/careui.instructions.md:0-0 Timestamp: 2025-11-25T13:50:46.407Z Learning: Applies to src/CAREUI/**/*.{test,spec}.{ts,tsx} : Implement comprehensive testing in CAREUI components including accessibility and medical workflow scenariosLearnt from: Jacobjeevan Repo: ohcnetwork/care_fe PR: 9145 File: cypress/e2e/facility_spec/FacilityHomepage.cy.ts:229-317 Timestamp: 2024-11-18T10:46:56.270Z Learning: In `cypress/e2e/facility_spec/FacilityHomepage.cy.ts`, when verifying the bed capacity badge reflection, the badge remains the same during multiple actions and only updates after a bed is attached to a patient during consultation. Therefore, it's appropriate to keep the test case consolidated rather than splitting it into smaller tests.Learnt from: Jacobjeevan Repo: ohcnetwork/care_fe PR: 9145 File: cypress/e2e/facility_spec/FacilityCreation.cy.ts:177-180 Timestamp: 2024-11-18T10:44:30.303Z Learning: In `cypress/e2e/facility_spec/FacilityCreation.cy.ts`, when testing bed and staff capacity individually for additional error verification, we prefer to use separate method calls to handle bed and staff capacity, rather than using `facilityPage.createNewFacility(testFacilityData)` which also handles bed management.Learnt from: CR Repo: ohcnetwork/care_fe PR: 0 File: .cursor/rules/02-coding-standards.mdc:0-0 Timestamp: 2025-11-25T13:54:09.978Z Learning: Applies to **/*.spec.ts : Write E2E tests in Playwright following https://playwright.dev/docs/writing-testsLearnt from: kihan2518B Repo: ohcnetwork/care_fe PR: 8956 File: cypress/e2e/facility_spec/FacilityCreation.cy.ts:261-261 Timestamp: 2024-12-04T18:58:47.241Z Learning: In `cypress/e2e/facility_spec/FacilityCreation.cy.ts`, the test case titled "Create a new facility with no bed and doctor capacity" includes steps to select bed types and specializations before validation. This is done intentionally to verify that error messages are shown properly when no capacity is specified.Learnt from: Jacobjeevan Repo: ohcnetwork/care_fe PR: 9145 File: cypress/e2e/patient_spec/PatientConsultationCreation.cy.ts:93-94 Timestamp: 2024-11-18T10:48:08.500Z Learning: In `cypress/e2e/patient_spec/PatientConsultationCreation.cy.ts`, bed capacity verification assertions after patient admission are already being performed elsewhere, so adding them here is unnecessary.Learnt from: yash-learner Repo: ohcnetwork/care_fe PR: 14108 File: tests/facility/settings/activityDefinitions/activityDefinitionCreate.spec.ts:86-147 Timestamp: 2025-11-20T09:48:26.486Z Learning: In tests/facility/settings/activityDefinitions/activityDefinitionCreate.spec.ts, detailed verification of selected values (e.g., code from value sets) in the detail view is intentionally deferred to the list spec, as the creation test focuses on the happy path and basic verification only.Learnt from: Jacobjeevan Repo: ohcnetwork/care_fe PR: 9080 File: cypress/pageobject/Users/ManageUserPage.ts:181-188 Timestamp: 2024-11-14T10:28:32.680Z Learning: In the Cypress tests for user management (`cypress/pageobject/Users/ManageUserPage.ts`), the method `verifyDoctorQualification()` is intended to verify qualifications specifically for the Doctor role.Learnt from: yash-learner Repo: ohcnetwork/care_fe PR: 14108 File: tests/facility/settings/activityDefinitions/activityDefinitionCreate.spec.ts:91-94 Timestamp: 2025-11-20T09:26:50.157Z Learning: In tests/facility/settings/activityDefinitions/activityDefinitionCreate.spec.ts, the hard-coded bounds for faker.number.int (e.g., 0-4, 0-2) when selecting itemIndex are intentionally based on stable backend seed data that is guaranteed to be available in the test environment, making the approach valid and not flaky.Learnt from: CR Repo: ohcnetwork/care_fe PR: 0 File: .github/instructions/pages.instructions.md:0-0 Timestamp: 2025-11-25T13:52:19.758Z Learning: Mock external dependencies in tests for page componentsLearnt from: CR Repo: ohcnetwork/care_fe PR: 0 File: .github/instructions/utils.instructions.md:0-0 Timestamp: 2025-11-25T13:53:40.623Z Learning: Applies to src/Utils/**/*.{ts,tsx} : Provide utilities for common testing scenarios in test utility filesLearnt from: nihal467 Repo: ohcnetwork/care_fe PR: 9846 File: cypress/pageObject/facility/FacilityCreation.ts:14-47 Timestamp: 2025-01-09T05:37:17.120Z Learning: In the care_fe project's Cypress tests, facility test data is managed through the facilityData.ts utility which provides pre-validated data through the FacilityTestData interface, making additional validation in the FacilityCreation page object unnecessary.Learnt from: CR Repo: ohcnetwork/care_fe PR: 0 File: .github/instructions/utils.instructions.md:0-0 Timestamp: 2025-11-25T13:53:40.623Z Learning: Applies to src/Utils/**/*.{ts,tsx} : Implement mock data generators as test utility functionsLearnt from: CR Repo: ohcnetwork/care_fe PR: 0 File: .github/instructions/providers.instructions.md:0-0 Timestamp: 2025-11-25T13:52:33.081Z Learning: Applies to src/Providers/**/*.{test,spec}.{ts,tsx} : Test provider state management and updates with comprehensive unit testsLearnt from: CR Repo: ohcnetwork/care_fe PR: 0 File: CLAUDE.md:0-0 Timestamp: 2025-11-25T13:53:49.727Z Learning: Run Playwright tests with `npm run playwright:test` for headless mode or `npm run playwright:test:ui` for interactive modeLearnt from: CR Repo: ohcnetwork/care_fe PR: 0 File: .github/instructions/context.instructions.md:0-0 Timestamp: 2025-11-25T13:51:23.408Z Learning: Applies to src/context/**/*.{test,spec}.{ts,tsx} : Test offline data handling in context tests
| const openCareTeamDialog = async (page: Page) => { | ||
| await page.getByRole("tab", { name: "Actions" }).click(); | ||
| await page.getByRole("button", { name: "Manage Care Team" }).click(); | ||
| await expect( | ||
| page.getByRole("dialog", { name: "Manage Care Team" }), | ||
| ).toBeVisible(); | ||
| }; |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Return the dialog locator and scope all subsequent assertions to it.
Right now, most locators in tests aren’t scoped to the “Manage Care Team” dialog, which can accidentally match other page elements (especially “Add”, “Remove”, “Administration”). Returning the dialog from openCareTeamDialog simplifies scoping and reduces flakiness.
Proposed diff (return dialog)
-test.use({ storageState: "tests/.auth/user.json" });
-
-const openCareTeamDialog = async (page: Page) => {
+test.use({ storageState: "tests/.auth/user.json" });
+
+async function openCareTeamDialog(page: Page) {
await page.getByRole("tab", { name: "Actions" }).click();
await page.getByRole("button", { name: "Manage Care Team" }).click();
- await expect(
- page.getByRole("dialog", { name: "Manage Care Team" }),
- ).toBeVisible();
-};
+ const dialog = page.getByRole("dialog", { name: "Manage Care Team" });
+ await expect(dialog).toBeVisible();
+ return dialog;
+}🤖 Prompt for AI Agents
In @tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts around lines
9 - 15, Modify openCareTeamDialog to return the dialog locator for the "Manage
Care Team" dialog (e.g., the result of page.getByRole("dialog", { name: "Manage
Care Team" })) and update callers to use that returned locator for all
subsequent queries and assertions (scope calls like getByRole, getByText, etc.
using dialog.locator(...) or dialog.getByRole(...)) so every interaction is
constrained to the dialog and avoids matching other page elements; keep the
existing clicks in openCareTeamDialog (tab and button) but return the dialog
locator instead of only asserting visibility.
| test("Add a care team member with role", async ({ page }) => { | ||
| await test.step("Open care team sheet", async () => { | ||
| await openCareTeamDialog(page); | ||
| }); | ||
|
|
||
| await test.step("Verify department selector", async () => { | ||
| await expect( | ||
| page.getByRole("combobox").filter({ hasText: "Select Department" }), | ||
| ).toBeVisible(); | ||
| await expect(page.getByText("Administration")).toBeVisible(); | ||
| }); | ||
|
|
||
| await test.step("Select member", async () => { | ||
| const memberSelector = page | ||
| .getByRole("combobox") | ||
| .filter({ hasText: "Select Member" }); | ||
| await expect(memberSelector).toBeEnabled(); | ||
| await memberSelector.click(); | ||
| await page.getByPlaceholder("Search").fill(username); | ||
| await page.getByText(username).click(); | ||
| }); | ||
|
|
||
| await test.step("Select role", async () => { | ||
| await page | ||
| .getByRole("combobox") | ||
| .filter({ hasText: "Select Role" }) | ||
| .click(); | ||
| await page.getByPlaceholder("Select Role").fill(selectedRole); | ||
| await page.getByRole("option", { name: selectedRole }).click(); | ||
| }); | ||
|
|
||
| await test.step("Add member", async () => { | ||
| await page.getByRole("button", { name: "Add" }).click(); | ||
| }); | ||
|
|
||
| await test.step("Verify member added", async () => { | ||
| await expectToast(page, /member added successfully/i); | ||
| const dialog = page.getByRole("dialog", { name: "Manage Care Team" }); | ||
| await expect(dialog.getByText(selectedRole)).toBeVisible(); | ||
| }); | ||
| }); |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cd tests/facility/patient/encounter/careTeam && wc -l linkCareTeam.spec.tsRepository: ohcnetwork/care_fe
Length of output: 86
🏁 Script executed:
cat -n tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts | head -100Repository: ohcnetwork/care_fe
Length of output: 4506
🏁 Script executed:
# Check if there are other test files with similar patterns for comparison
fd '\.spec\.ts$' tests/ | head -10Repository: ohcnetwork/care_fe
Length of output: 506
🏁 Script executed:
# Search for similar dialog+selector patterns in other test files to understand the codebase practices
rg 'getByRole.*dialog' tests/ -A 3 -B 1 --type ts | head -40Repository: ohcnetwork/care_fe
Length of output: 2731
Scope all selectors to the dialog context and avoid placeholder-based selectors.
The test uses unscoped selectors (lines 64–89) that can match elements outside the dialog, making tests fragile. Placeholders like "Search" and "Select Role" are brittle for i18n—they'll break when translated. Move const dialog = page.getByRole("dialog", { name: "Manage Care Team" }); to the start and use dialog.getByRole(...), dialog.getByText(...) throughout. For the member selector with "Search", use dialog.getByRole("option") to select by username instead of the placeholder.
🤖 Prompt for AI Agents
In @tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts around lines
57 - 97, Move the dialog lookup to the start of the test (inside test("Add a
care team member with role" ...)) by creating const dialog =
page.getByRole("dialog", { name: "Manage Care Team" }); immediately after
opening the care team sheet, then replace all unscoped page.* selectors with
dialog.* (e.g., dialog.getByRole("combobox").filter(...),
dialog.getByText(...)). Remove placeholder-based selectors: for selecting the
member use dialog.getByRole("option", { name: username }) (instead of
getByPlaceholder("Search").fill and clicking by text), and for selecting the
role use dialog.getByRole("option", { name: selectedRole }) (instead of
getByPlaceholder("Select Role").fill); keep the final verification using
dialog.getByText(selectedRole).
| test("Cannot add same member with same role twice", async ({ page }) => { | ||
| await test.step("Open care team sheet", async () => { | ||
| await openCareTeamDialog(page); | ||
| }); | ||
|
|
||
| await test.step("Add member first time", async () => { | ||
| const memberSelector = page | ||
| .getByRole("combobox") | ||
| .filter({ hasText: "Select Member" }); | ||
| await memberSelector.click(); | ||
| await page.getByPlaceholder("Search").fill(username); | ||
| await page.getByText(username).click(); | ||
|
|
||
| await page | ||
| .getByRole("combobox") | ||
| .filter({ hasText: "Select Role" }) | ||
| .click(); | ||
| await page.getByPlaceholder("Select Role").fill(selectedRole); | ||
| await page.getByRole("option", { name: selectedRole }).click(); | ||
|
|
||
| await page.getByRole("button", { name: "Add" }).click(); | ||
| await expectToast(page, /member added successfully/i); | ||
| }); | ||
|
|
||
| await test.step("Try to add same member with same role again", async () => { | ||
| const memberSelector = page | ||
| .getByRole("combobox") | ||
| .filter({ hasText: "Select Member" }); | ||
| await memberSelector.click(); | ||
| await page.getByPlaceholder("Search").fill(username); | ||
| await page.getByText(username).click(); | ||
|
|
||
| await page | ||
| .getByRole("combobox") | ||
| .filter({ hasText: "Select Role" }) | ||
| .click(); | ||
| await page.getByPlaceholder("Select Role").fill(selectedRole); | ||
| await page.getByRole("option", { name: selectedRole }).click(); | ||
|
|
||
| await page.getByRole("button", { name: "Add" }).click(); | ||
| await expectToast(page, /already added|already exists|duplicate/i); | ||
| }); | ||
| }); |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Duplicate-add test should also assert no second entry is created.
The toast assertion (Line 139-140) is good, but the test should verify the UI doesn’t show a duplicated row/role entry afterward (count remains 1). This prevents false positives where the toast is shown but state is still corrupted.
🤖 Prompt for AI Agents
In @tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts around lines
99 - 141, After the duplicate-add step in the "Cannot add same member with same
role twice" test (after the expectToast call), add an assertion that the care
team UI contains only one entry for the given username/selectedRole pair: locate
the care-team rows/entries that include username and selectedRole (reusing the
same selectors used earlier after openCareTeamDialog) and assert their count is
exactly 1 so the UI state wasn’t duplicated; keep this check immediately after
the duplicate-add expectToast and reference the test, openCareTeamDialog,
username, and selectedRole identifiers.
| test("Add button is disabled initially when opening care team sheet", async ({ | ||
| page, | ||
| }) => { | ||
| await test.step("Open care team sheet", async () => { | ||
| await openCareTeamDialog(page); | ||
| await expect(page.getByText("Administration")).toBeVisible(); | ||
| }); | ||
|
|
||
| await test.step("Verify Add button is disabled", async () => { | ||
| await expect(page.getByRole("button", { name: "Add" })).toBeDisabled(); | ||
| }); | ||
| }); |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
find . -name "linkCareTeam.spec.ts" -type fRepository: ohcnetwork/care_fe
Length of output: 126
🏁 Script executed:
cat -n tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts | head -250Repository: ohcnetwork/care_fe
Length of output: 10310
🏁 Script executed:
# Search for similar dialog assertions in the codebase to understand patterns
rg "getByRole.*dialog" tests/ -A 3 -B 3 | head -100Repository: ohcnetwork/care_fe
Length of output: 6846
Scope "Add" button assertions to the Manage Care Team dialog.
page.getByRole("button", { name: "Add" }) can match other "Add" buttons on the page. Use a dialog-scoped locator to ensure you're testing the right control.
const dialog = page.getByRole("dialog", { name: "Manage Care Team" });
await expect(dialog.getByRole("button", { name: "Add" })).toBeDisabled();
🤖 Prompt for AI Agents
In @tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts around lines
144 - 155, The test currently uses page.getByRole("button", { name: "Add" })
which may match other "Add" buttons; change the assertion to scope it to the
Manage Care Team dialog by locating the dialog (use page.getByRole("dialog", {
name: "Manage Care Team" }) and store it, e.g., const dialog) and then assert on
dialog.getByRole("button", { name: "Add" }) in the "Verify Add button is
disabled" step (this ensures the assertion targets the care team sheet opened by
openCareTeamDialog).
🎭 Playwright Test ResultsStatus: ✅ Passed
📊 Detailed results are available in the playwright-final-report artifact. Run: #4465 |
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Fix all issues with AI agents
In @tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts:
- Around line 171-210: The verification is brittle because asserting
dialog.getByText(selectedUsername) and dialog.getByText(selectedRole) can
produce false negatives if other members share those strings; instead update the
"Verify member was not added" step in this test to assert a more specific
condition such as (a) capture the initial member count before the add attempt
(using the dialog locator returned by openCareTeamDialog or the same
dialog.getByRole("dialog", { name: "Manage Care Team" })) and assert the count
unchanged after closing, or (b) assert absence of a specific member row that
combines both selectedUsername and selectedRole (e.g., locate a row/button that
contains both values) so you check the composite entry rather than individual
text nodes; use the existing selectedUsername/selectedRole and the dialog
locator to implement this change.
- Around line 29-39: Before calling page.getByText("View
Encounter").first().click() in the test.beforeEach block, verify at least one
"View Encounter" element exists and is visible; for example, obtain the locator
for page.getByText("View Encounter"), wait for it to be visible or assert its
count is > 0 (so the test fails with a clear timeout if no encounters are
present) before proceeding to click the first one.
📜 Review details
Configuration used: Repository UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (1)
tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts
🧰 Additional context used
📓 Path-based instructions (7)
**/*.{ts,tsx}
📄 CodeRabbit inference engine (.cursorrules)
**/*.{ts,tsx}: Write concise, technical TypeScript code with accurate examples
Use TypeScript for all code; prefer interfaces over types
Avoid enums; use maps instead
Use TanStack Query for data fetching from the API along with query and mutate utilities for the queryFn and mutationFn
Use raviger for routing
**/*.{ts,tsx}: Use TypeScript with strict mode and ES2022 target
Useinterfacefor defining object types in TypeScript
Avoid explicitanytype in TypeScript
Use proper nullability annotations in TypeScript types
Use dedicated error handlers and TypeScript strict null checks
**/*.{ts,tsx}: Use TypeScript for all new code
Prefer interfaces over types for object definitions in TypeScript
Avoid usinganytype; use proper type definitions in TypeScript
Use type inference where possible in TypeScript
Use TanStack Query for API data management
Prefer React Context for global state management
**/*.{ts,tsx}: Use TanStack Query with thequeryandmutateutilities from@/Utils/request/
Use appropriate query keys following the resource pattern for TanStack Query
Leverage TanStack Query built-in features for pagination and debouncing
Implement proper error handling using the global error handler for TanStack Query operations
UseuseQueryhook withqueryKeyandqueryFnparameters, wherequeryFnwraps the API route with thequery()utility
UseuseMutationhook withmutationFnparameter wrapping API routes with themutate()utility, and implementonSuccesscallbacks to invalidate related queries
Support path parameters in TanStack Query using thepathParamsoption in query/mutate utilities
Support query parameters in TanStack Query using thequeryParamsoption in query/mutate utilities
Use thesilent: trueoption to suppress global error notifications when custom error handling is needed
**/*.{ts,tsx}: Use TypeScript with strict mode and ES2022 target
Useinterfacefor defining object types
Avoid explicitanytypes and maint...
Files:
tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts
**/*.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (.cursorrules)
**/*.{ts,tsx,js,jsx}: Use functional and declarative programming patterns; avoid classes
Prefer iteration and modularization over code duplication
Use descriptive variable names with auxiliary verbs (e.g., isLoading, hasError)
Use the "function" keyword for pure functions
Avoid unnecessary curly braces in conditionals; use concise syntax for simple statements
**/*.{ts,tsx,js,jsx}: Use path aliases for imports from src (@/*)
Use double quotes for strings
Semicolons are required at end of statements
Order imports as: 3rd-party → library → CAREUI → UI → components → hooks → utils → relative
Use PascalCase for component and class names
Use camelCase for variable and function names
**/*.{ts,tsx,js,jsx}: Use path aliases@/*for imports from src directory
Use double quotes for strings
Require semicolons at end of statements
Order imports: 3rd-party → library → CAREUI → UI → components → hooks → utils → relative
Use PascalCase for component and class names
Use camelCase for variable and function names
Files:
tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts
**/*
📄 CodeRabbit inference engine (CLAUDE.md)
Use 2-space indentation
Files:
tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts
**/*.ts
📄 CodeRabbit inference engine (.cursor/rules/02-coding-standards.mdc)
Use camelCase for utility file names (e.g.,
useAuth.ts)
Files:
tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts
**/*.spec.ts
📄 CodeRabbit inference engine (.cursor/rules/02-coding-standards.mdc)
**/*.spec.ts: Write E2E tests in Playwright following https://playwright.dev/docs/writing-tests
Write meaningful test descriptions
Files:
tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts
**/*.{tsx,ts}
📄 CodeRabbit inference engine (.cursor/rules/04-ui-components.mdc)
**/*.{tsx,ts}: Use Shadcn UI components as the primary component library
Follow the component documentation for proper usage
Customize components using Tailwind CSS
UsenavigateanduseRedirectfrom raviger for navigation and redirects
Use Tailwind's responsive classes and follow mobile-first approach
Implement proper ARIA attributes for accessibility
Ensure keyboard navigation works in components
Define component props using TypeScript interfaces
Use translation keys fromsrc/Locale/for internationalization
Support RTL languages in components
Use proper date/time formatting for multiple language support
Files:
tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts
**/*.{ts,tsx,js,jsx,json,css,scss,html}
📄 CodeRabbit inference engine (AGENTS.md)
Use 2-space indentation
Files:
tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts
🧠 Learnings (33)
📓 Common learnings
Learnt from: CR
Repo: ohcnetwork/care_fe PR: 0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-11-25T13:50:10.786Z
Learning: Playwright E2E tests required for critical healthcare workflows and must be run before deployment
Learnt from: CR
Repo: ohcnetwork/care_fe PR: 0
File: .github/instructions/careui.instructions.md:0-0
Timestamp: 2025-11-25T13:50:46.407Z
Learning: Applies to src/CAREUI/**/*.{test,spec}.{ts,tsx} : Implement comprehensive testing in CAREUI components including accessibility and medical workflow scenarios
Learnt from: CR
Repo: ohcnetwork/care_fe PR: 0
File: .cursor/rules/02-coding-standards.mdc:0-0
Timestamp: 2025-11-25T13:54:09.978Z
Learning: Applies to **/*.spec.ts : Write E2E tests in Playwright following https://playwright.dev/docs/writing-tests
Learnt from: CR
Repo: ohcnetwork/care_fe PR: 0
File: .github/instructions/careui.instructions.md:0-0
Timestamp: 2025-11-25T13:50:46.407Z
Learning: Include automated accessibility testing in CI/CD for CAREUI components
Learnt from: Jacobjeevan
Repo: ohcnetwork/care_fe PR: 9080
File: cypress/pageobject/Users/ManageUserPage.ts:181-188
Timestamp: 2024-11-14T10:28:32.680Z
Learning: In the Cypress tests for user management (`cypress/pageobject/Users/ManageUserPage.ts`), the method `verifyDoctorQualification()` is intended to verify qualifications specifically for the Doctor role.
Learnt from: CR
Repo: ohcnetwork/care_fe PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-25T13:53:49.727Z
Learning: Run Playwright tests with `npm run playwright:test` for headless mode or `npm run playwright:test:ui` for interactive mode
Learnt from: kihan2518B
Repo: ohcnetwork/care_fe PR: 8956
File: cypress/e2e/facility_spec/FacilityCreation.cy.ts:261-261
Timestamp: 2024-12-04T18:58:47.241Z
Learning: In `cypress/e2e/facility_spec/FacilityCreation.cy.ts`, the test case titled "Create a new facility with no bed and doctor capacity" includes steps to select bed types and specializations before validation. This is done intentionally to verify that error messages are shown properly when no capacity is specified.
Learnt from: Jacobjeevan
Repo: ohcnetwork/care_fe PR: 9145
File: cypress/e2e/patient_spec/PatientConsultationCreation.cy.ts:93-94
Timestamp: 2024-11-18T10:48:08.500Z
Learning: In `cypress/e2e/patient_spec/PatientConsultationCreation.cy.ts`, bed capacity verification assertions after patient admission are already being performed elsewhere, so adding them here is unnecessary.
Learnt from: nihal467
Repo: ohcnetwork/care_fe PR: 9846
File: cypress/pageObject/facility/FacilityCreation.ts:14-47
Timestamp: 2025-01-09T05:37:17.120Z
Learning: In the care_fe project's Cypress tests, facility test data is managed through the facilityData.ts utility which provides pre-validated data through the FacilityTestData interface, making additional validation in the FacilityCreation page object unnecessary.
Learnt from: CR
Repo: ohcnetwork/care_fe PR: 0
File: .github/instructions/providers.instructions.md:0-0
Timestamp: 2025-11-25T13:52:33.081Z
Learning: Applies to src/Providers/**/*.{test,spec}.{ts,tsx} : Test provider state management and updates with comprehensive unit tests
📚 Learning: 2025-11-25T13:50:46.407Z
Learnt from: CR
Repo: ohcnetwork/care_fe PR: 0
File: .github/instructions/careui.instructions.md:0-0
Timestamp: 2025-11-25T13:50:46.407Z
Learning: Applies to src/CAREUI/**/*.{test,spec}.{ts,tsx} : Implement comprehensive testing in CAREUI components including accessibility and medical workflow scenarios
Applied to files:
tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts
📚 Learning: 2026-01-02T12:19:24.476Z
Learnt from: SiddanthNayak
Repo: ohcnetwork/care_fe PR: 14906
File: tests/facility/overview/overview.spec.ts:6-39
Timestamp: 2026-01-02T12:19:24.476Z
Learning: In facility tests (e.g., tests/facility/overview/overview.spec.ts and similar), URL assertions may include dynamic filters/query parameters. Use .toContain() (or similar contains-based checks) instead of exact URL matches (like toHaveURL or strict equality) to accommodate runtime-added query parameters. Apply this approach to all relevant facility-spec.ts files.
Applied to files:
tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts
📚 Learning: 2024-11-18T10:48:08.500Z
Learnt from: Jacobjeevan
Repo: ohcnetwork/care_fe PR: 9145
File: cypress/e2e/patient_spec/PatientConsultationCreation.cy.ts:93-94
Timestamp: 2024-11-18T10:48:08.500Z
Learning: In `cypress/e2e/patient_spec/PatientConsultationCreation.cy.ts`, bed capacity verification assertions after patient admission are already being performed elsewhere, so adding them here is unnecessary.
Applied to files:
tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts
📚 Learning: 2024-12-04T18:58:47.241Z
Learnt from: kihan2518B
Repo: ohcnetwork/care_fe PR: 8956
File: cypress/e2e/facility_spec/FacilityCreation.cy.ts:261-261
Timestamp: 2024-12-04T18:58:47.241Z
Learning: In `cypress/e2e/facility_spec/FacilityCreation.cy.ts`, the test case titled "Create a new facility with no bed and doctor capacity" includes steps to select bed types and specializations before validation. This is done intentionally to verify that error messages are shown properly when no capacity is specified.
Applied to files:
tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts
📚 Learning: 2025-11-25T13:54:09.978Z
Learnt from: CR
Repo: ohcnetwork/care_fe PR: 0
File: .cursor/rules/02-coding-standards.mdc:0-0
Timestamp: 2025-11-25T13:54:09.978Z
Learning: Applies to **/*.spec.ts : Write E2E tests in Playwright following https://playwright.dev/docs/writing-tests
Applied to files:
tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts
📚 Learning: 2025-11-25T13:50:46.407Z
Learnt from: CR
Repo: ohcnetwork/care_fe PR: 0
File: .github/instructions/careui.instructions.md:0-0
Timestamp: 2025-11-25T13:50:46.407Z
Learning: Applies to src/CAREUI/**/*.{ts,tsx} : Use standard medical component interface patterns with medicalContext, accessibility properties (ariaLabel, screenReaderText), clinical validation callbacks (onValidationError), and medical data properties (patientId, facilityId)
Applied to files:
tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts
📚 Learning: 2024-11-18T10:46:56.270Z
Learnt from: Jacobjeevan
Repo: ohcnetwork/care_fe PR: 9145
File: cypress/e2e/facility_spec/FacilityHomepage.cy.ts:229-317
Timestamp: 2024-11-18T10:46:56.270Z
Learning: In `cypress/e2e/facility_spec/FacilityHomepage.cy.ts`, when verifying the bed capacity badge reflection, the badge remains the same during multiple actions and only updates after a bed is attached to a patient during consultation. Therefore, it's appropriate to keep the test case consolidated rather than splitting it into smaller tests.
Applied to files:
tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts
📚 Learning: 2024-11-18T10:44:30.303Z
Learnt from: Jacobjeevan
Repo: ohcnetwork/care_fe PR: 9145
File: cypress/e2e/facility_spec/FacilityCreation.cy.ts:177-180
Timestamp: 2024-11-18T10:44:30.303Z
Learning: In `cypress/e2e/facility_spec/FacilityCreation.cy.ts`, when testing bed and staff capacity individually for additional error verification, we prefer to use separate method calls to handle bed and staff capacity, rather than using `facilityPage.createNewFacility(testFacilityData)` which also handles bed management.
Applied to files:
tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts
📚 Learning: 2025-11-20T09:48:26.486Z
Learnt from: yash-learner
Repo: ohcnetwork/care_fe PR: 14108
File: tests/facility/settings/activityDefinitions/activityDefinitionCreate.spec.ts:86-147
Timestamp: 2025-11-20T09:48:26.486Z
Learning: In tests/facility/settings/activityDefinitions/activityDefinitionCreate.spec.ts, detailed verification of selected values (e.g., code from value sets) in the detail view is intentionally deferred to the list spec, as the creation test focuses on the happy path and basic verification only.
Applied to files:
tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts
📚 Learning: 2025-01-09T05:37:17.120Z
Learnt from: nihal467
Repo: ohcnetwork/care_fe PR: 9846
File: cypress/pageObject/facility/FacilityCreation.ts:14-47
Timestamp: 2025-01-09T05:37:17.120Z
Learning: In the care_fe project's Cypress tests, facility test data is managed through the facilityData.ts utility which provides pre-validated data through the FacilityTestData interface, making additional validation in the FacilityCreation page object unnecessary.
Applied to files:
tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts
📚 Learning: 2025-01-09T05:38:42.398Z
Learnt from: nihal467
Repo: ohcnetwork/care_fe PR: 9846
File: cypress/fixtures/users.json:11-12
Timestamp: 2025-01-09T05:38:42.398Z
Learning: In the care_fe project, test usernames in cypress/fixtures/users.json intentionally use personal identifiers with the "nihal-" prefix.
Applied to files:
tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts
📚 Learning: 2024-11-12T12:06:30.851Z
Learnt from: Jacobjeevan
Repo: ohcnetwork/care_fe PR: 9080
File: src/components/Users/LinkedFacilitiesTab.tsx:7-11
Timestamp: 2024-11-12T12:06:30.851Z
Learning: In `src/components/Users/LinkedFacilitiesTab.tsx`, the `username` prop is used when passing it to the `userColumns` function, so it should not be considered unused.
Applied to files:
tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts
📚 Learning: 2025-01-15T11:04:16.327Z
Learnt from: nihal467
Repo: ohcnetwork/care_fe PR: 9986
File: cypress/utils/commonUtils.ts:73-81
Timestamp: 2025-01-15T11:04:16.327Z
Learning: The Cypress tests in the care_fe repository are designed to run only in the development environment, and the username generation utility uses a hardcoded "dev" suffix.
Applied to files:
tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts
📚 Learning: 2025-01-09T05:39:33.668Z
Learnt from: nihal467
Repo: ohcnetwork/care_fe PR: 9846
File: cypress/e2e/login_spec/loginpage.cy.ts:18-18
Timestamp: 2025-01-09T05:39:33.668Z
Learning: In the login test suite (cypress/e2e/login_spec/loginpage.cy.ts), the test case "should successfully login with admin credentials" intentionally uses staff role instead of admin role.
Applied to files:
tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts
📚 Learning: 2024-11-05T16:59:23.732Z
Learnt from: AnveshNalimela
Repo: ohcnetwork/care_fe PR: 8930
File: cypress/pageobject/Users/UserCreation.ts:16-59
Timestamp: 2024-11-05T16:59:23.732Z
Learning: In the `cypress/pageobject/Users/UserCreation.ts` file, method parameter names may use a mix of `snake_case` and `camelCase` naming conventions, and this is acceptable in the codebase.
Applied to files:
tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts
📚 Learning: 2024-12-04T07:06:49.613Z
Learnt from: nihal467
Repo: ohcnetwork/care_fe PR: 9285
File: cypress/e2e/patient_spec/PatientDoctorNotes.cy.ts:17-17
Timestamp: 2024-12-04T07:06:49.613Z
Learning: In `PatientDoctorNotes.cy.ts`, the login methods `loginManuallyAsNurse()` and `loginByRole("nurse")` serve different purposes and approaches. Refactoring `loginManuallyAsNurse()` to use `loginByRole()` is not necessary in this context.
Applied to files:
tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts
📚 Learning: 2024-11-14T10:29:07.447Z
Learnt from: Jacobjeevan
Repo: ohcnetwork/care_fe PR: 9080
File: cypress/e2e/users_spec/UsersManage.cy.ts:129-131
Timestamp: 2024-11-14T10:29:07.447Z
Learning: In the Cypress test files (e.g., `cypress/e2e/users_spec/UsersManage.cy.ts`), it is acceptable to use hardcoded English error messages, as testing is conducted in English.
Applied to files:
tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts
📚 Learning: 2024-11-14T10:28:32.680Z
Learnt from: Jacobjeevan
Repo: ohcnetwork/care_fe PR: 9080
File: cypress/pageobject/Users/ManageUserPage.ts:181-188
Timestamp: 2024-11-14T10:28:32.680Z
Learning: In the Cypress tests for user management (`cypress/pageobject/Users/ManageUserPage.ts`), the method `verifyDoctorQualification()` is intended to verify qualifications specifically for the Doctor role.
Applied to files:
tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts
📚 Learning: 2025-11-25T13:51:23.408Z
Learnt from: CR
Repo: ohcnetwork/care_fe PR: 0
File: .github/instructions/context.instructions.md:0-0
Timestamp: 2025-11-25T13:51:23.408Z
Learning: Applies to src/context/**/*.{test,spec}.{ts,tsx} : Test role-based access control in context implementations
Applied to files:
tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts
📚 Learning: 2024-11-22T12:04:39.044Z
Learnt from: Jacobjeevan
Repo: ohcnetwork/care_fe PR: 9080
File: src/components/Users/UserSummary.tsx:53-71
Timestamp: 2024-11-22T12:04:39.044Z
Learning: In the `UserSummaryTab` component (`src/components/Users/UserSummary.tsx`), when there is an error during user deletion, the delete dialog is intentionally closed to prevent the user from immediately trying to delete the user again.
Applied to files:
tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts
📚 Learning: 2024-12-05T04:20:20.231Z
Learnt from: nihal467
Repo: ohcnetwork/care_fe PR: 9301
File: cypress/e2e/facility_spec/FacilityLocation.cy.ts:220-220
Timestamp: 2024-12-05T04:20:20.231Z
Learning: In `FacilityLocation.cy.ts`, ensure not to suggest adding success message verifications if they are already present in the test steps.
Applied to files:
tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts
📚 Learning: 2025-08-19T13:02:09.801Z
Learnt from: AdityaJ2305
Repo: ohcnetwork/care_fe PR: 13395
File: src/pages/Facility/settings/locations/components/LocationTable.tsx:288-300
Timestamp: 2025-08-19T13:02:09.801Z
Learning: Refactoring from AlertDialogTrigger-wrapped buttons to separate state-controlled dialogs (where button updates state and dialog opens based on state) naturally prevents focus return to trigger on dialog close, solving tooltip reappearance issues without needing onCloseAutoFocus.
Applied to files:
tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts
📚 Learning: 2025-05-19T16:41:44.446Z
Learnt from: hrit2773
Repo: ohcnetwork/care_fe PR: 11922
File: cypress/pageObject/Patients/PatientEncounter.ts:140-164
Timestamp: 2025-05-19T16:41:44.446Z
Learning: The PatientEncounter class in Cypress tests intentionally uses different element targeting strategies: `position: "first"` for allergies and `position: "last"` for symptoms and diagnoses, reflecting the different UI behaviors of these components.
Applied to files:
tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts
📚 Learning: 2025-11-25T13:51:23.408Z
Learnt from: CR
Repo: ohcnetwork/care_fe PR: 0
File: .github/instructions/context.instructions.md:0-0
Timestamp: 2025-11-25T13:51:23.408Z
Learning: Applies to src/context/**/*.{test,spec}.{ts,tsx} : Verify audit trail completeness in context tests
Applied to files:
tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts
📚 Learning: 2025-11-25T13:51:23.408Z
Learnt from: CR
Repo: ohcnetwork/care_fe PR: 0
File: .github/instructions/context.instructions.md:0-0
Timestamp: 2025-11-25T13:51:23.408Z
Learning: Applies to src/context/**/*.{test,spec}.{ts,tsx} : Validate emergency override scenarios in context tests
Applied to files:
tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts
📚 Learning: 2024-11-14T08:09:58.453Z
Learnt from: Jacobjeevan
Repo: ohcnetwork/care_fe PR: 9080
File: cypress/pageobject/Users/ManageUserPage.ts:67-97
Timestamp: 2024-11-14T08:09:58.453Z
Learning: In Cypress test files (`cypress/pageobject/Users/ManageUserPage.ts`), when methods are called to check input provided earlier in the test, adding TypeScript interfaces, input validation, and custom error messages is unnecessary.
Applied to files:
tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts
📚 Learning: 2025-11-25T13:50:46.407Z
Learnt from: CR
Repo: ohcnetwork/care_fe PR: 0
File: .github/instructions/careui.instructions.md:0-0
Timestamp: 2025-11-25T13:50:46.407Z
Learning: Applies to src/CAREUI/**/*.{ts,tsx} : Implement comprehensive screen reader support - All medical data must be accessible via assistive technology with proper ARIA labels for medical context and urgency
Applied to files:
tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts
📚 Learning: 2025-11-25T13:52:19.758Z
Learnt from: CR
Repo: ohcnetwork/care_fe PR: 0
File: .github/instructions/pages.instructions.md:0-0
Timestamp: 2025-11-25T13:52:19.758Z
Learning: Applies to src/pages/**/*.{ts,tsx} : Use proper ARIA labels and roles in page components
Applied to files:
tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts
📚 Learning: 2025-01-15T11:05:16.663Z
Learnt from: nihal467
Repo: ohcnetwork/care_fe PR: 9986
File: cypress/e2e/users_spec/user_creation.cy.ts:43-55
Timestamp: 2025-01-15T11:05:16.663Z
Learning: UI verification for user creation in the users list should be implemented only after search functionality is available in the UI to avoid flaky tests. Currently, the test focuses on API verification only.
Applied to files:
tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts
📚 Learning: 2025-01-19T14:12:10.781Z
Learnt from: AdityaJ2305
Repo: ohcnetwork/care_fe PR: 10054
File: src/components/Users/CreateUserForm.tsx:278-297
Timestamp: 2025-01-19T14:12:10.781Z
Learning: When using Cypress with React forms that have real-time validation, use `should('be.visible')` before typing and add `{ force: true }` option or break down type commands into smaller chunks with intermediate assertions to handle DOM detachment issues.
Applied to files:
tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts
📚 Learning: 2025-11-25T13:50:46.407Z
Learnt from: CR
Repo: ohcnetwork/care_fe PR: 0
File: .github/instructions/careui.instructions.md:0-0
Timestamp: 2025-11-25T13:50:46.407Z
Learning: Applies to src/CAREUI/**/*.{ts,tsx} : Provide clear and visible focus indicators for complex medical workflows in CAREUI components
Applied to files:
tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts
📚 Learning: 2026-01-02T18:04:26.656Z
Learnt from: shiv7shukla
Repo: ohcnetwork/care_fe PR: 14986
File: tests/organization/patient/searchpatient/keyboardNavigation.spec.ts:8-8
Timestamp: 2026-01-02T18:04:26.656Z
Learning: In Playwright tests (e.g., tests/organization/patient/searchpatient/keyboardNavigation.spec.ts), when simulating keyboard shortcuts that could trigger the browser's search (Ctrl+K), use a lowercase 'k' (e.g., 'Control+k') to prevent the browser search bar from opening. This ensures test interactions are not disrupted. Apply this guideline to all Playwright test files that simulate shortcuts.
Applied to files:
tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts
🧬 Code graph analysis (1)
tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts (2)
tests/support/facilityId.ts (1)
getFacilityId(12-43)tests/helper/ui.ts (1)
expectToast(426-433)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: Test
- GitHub Check: CodeQL-Build
🔇 Additional comments (6)
tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts (6)
1-15: LGTM! Well-structured imports and helper function.The imports follow the proper order, and the
openCareTeamDialoghelper function promotes code reusability while maintaining clean test structure.
71-111: LGTM! Well-structured test with clear steps.The test properly verifies each stage of adding a care team member, including UI state checks and success toast verification.
113-155: Verify the exact duplicate error message.The regex pattern
/already added|already exists|duplicate/iis quite permissive and might match unintended error messages. If the exact error message from the API is known, use a more specific pattern for better test accuracy.For example, if the API returns a specific message like "Care team member already exists", update line 153:
await expectToast(page, /care team member already exists/i);If the message varies, document the possible variations in a comment for future maintainers.
158-169: LGTM! Clear initial state verification.Simple and effective test for the initial disabled state of the Add button.
212-249: LGTM! Excellent progressive state validation.The test effectively verifies the button state transitions through each step of the member selection flow, ensuring proper UI validation.
22-27: Consider moving test data to a fixture file.The hardcoded usernames and roles could be externalized to a test data fixture (similar to how user credentials are managed in other test files). This would improve maintainability and make it easier to manage environment-specific test data.
Example fixture structure
Create a file like
tests/fixtures/careTeamData.ts:export const CARE_TEAM_TEST_DATA = { usernames: ["care-admin", "care-fac-admin", "administrator_2_0"], roles: [ "Primary healthcare service", "Acupuncturist", "Orthotist and prosthetist", ], };Then import and use:
import { CARE_TEAM_TEST_DATA } from "tests/fixtures/careTeamData"; // ... selectedUsername = faker.helpers.arrayElement(CARE_TEAM_TEST_DATA.usernames);⛔ Skipped due to learnings
Learnt from: nihal467 Repo: ohcnetwork/care_fe PR: 9846 File: cypress/fixtures/users.json:11-12 Timestamp: 2025-01-09T05:38:42.398Z Learning: In the care_fe project, test usernames in cypress/fixtures/users.json intentionally use personal identifiers with the "nihal-" prefix.Learnt from: yash-learner Repo: ohcnetwork/care_fe PR: 14108 File: tests/facility/settings/activityDefinitions/activityDefinitionCreate.spec.ts:91-94 Timestamp: 2025-11-20T09:26:50.157Z Learning: In tests/facility/settings/activityDefinitions/activityDefinitionCreate.spec.ts, the hard-coded bounds for faker.number.int (e.g., 0-4, 0-2) when selecting itemIndex are intentionally based on stable backend seed data that is guaranteed to be available in the test environment, making the approach valid and not flaky.Learnt from: nihal467 Repo: ohcnetwork/care_fe PR: 9846 File: cypress/pageObject/facility/FacilityCreation.ts:14-47 Timestamp: 2025-01-09T05:37:17.120Z Learning: In the care_fe project's Cypress tests, facility test data is managed through the facilityData.ts utility which provides pre-validated data through the FacilityTestData interface, making additional validation in the FacilityCreation page object unnecessary.Learnt from: Jacobjeevan Repo: ohcnetwork/care_fe PR: 9080 File: cypress/pageobject/Users/ManageUserPage.ts:181-188 Timestamp: 2024-11-14T10:28:32.680Z Learning: In the Cypress tests for user management (`cypress/pageobject/Users/ManageUserPage.ts`), the method `verifyDoctorQualification()` is intended to verify qualifications specifically for the Doctor role.Learnt from: CR Repo: ohcnetwork/care_fe PR: 0 File: .github/instructions/context.instructions.md:0-0 Timestamp: 2025-11-25T13:51:23.408Z Learning: Applies to src/context/**/*.{test,spec}.{ts,tsx} : Test role-based access control in context implementationsLearnt from: Jacobjeevan Repo: ohcnetwork/care_fe PR: 9080 File: cypress/pageobject/Users/ManageUserPage.ts:67-97 Timestamp: 2024-11-14T08:09:58.453Z Learning: In Cypress test files (`cypress/pageobject/Users/ManageUserPage.ts`), when methods are called to check input provided earlier in the test, adding TypeScript interfaces, input validation, and custom error messages is unnecessary.Learnt from: CR Repo: ohcnetwork/care_fe PR: 0 File: .github/instructions/utils.instructions.md:0-0 Timestamp: 2025-11-25T13:53:40.623Z Learning: Applies to src/Utils/**/*.{ts,tsx} : Create test helpers and fixtures as separate utility files; keep test utilities separate from production codeLearnt from: nihal467 Repo: ohcnetwork/care_fe PR: 9846 File: cypress/e2e/login_spec/loginpage.cy.ts:18-18 Timestamp: 2025-01-09T05:39:33.668Z Learning: In the login test suite (cypress/e2e/login_spec/loginpage.cy.ts), the test case "should successfully login with admin credentials" intentionally uses staff role instead of admin role.Learnt from: CR Repo: ohcnetwork/care_fe PR: 0 File: .github/instructions/careui.instructions.md:0-0 Timestamp: 2025-11-25T13:50:46.407Z Learning: Applies to src/CAREUI/**/*.{test,spec}.{ts,tsx} : Implement comprehensive testing in CAREUI components including accessibility and medical workflow scenariosLearnt from: Jacobjeevan Repo: ohcnetwork/care_fe PR: 9080 File: cypress/e2e/users_spec/UsersManage.cy.ts:129-131 Timestamp: 2024-11-14T10:29:07.447Z Learning: In the Cypress test files (e.g., `cypress/e2e/users_spec/UsersManage.cy.ts`), it is acceptable to use hardcoded English error messages, as testing is conducted in English.Learnt from: CR Repo: ohcnetwork/care_fe PR: 0 File: .github/instructions/common.instructions.md:0-0 Timestamp: 2025-11-25T13:50:54.683Z Learning: Applies to src/common/**/Permissions.tsx : Implement role-based access control for medical staff with Doctor, Nurse, and Admin roles in Permissions.tsxLearnt from: CR Repo: ohcnetwork/care_fe PR: 0 File: .github/instructions/context.instructions.md:0-0 Timestamp: 2025-11-25T13:51:23.408Z Learning: Applies to src/context/**/PermissionContext.tsx : Implement PermissionContext with medical role-based permissions (Doctor, Nurse, Admin, Pharmacist) including patient data access control with dynamic permission checking and facility-level permissions for multi-facility healthcare systems
| test.beforeEach(async ({ page }) => { | ||
| facilityId = getFacilityId(); | ||
| selectedUsername = faker.helpers.arrayElement(TEST_USERNAMES); | ||
| selectedRole = faker.helpers.arrayElement(TEST_ROLES); | ||
| const createdDateAfter = format(subDays(new Date(), 90), "yyyy-MM-dd"); | ||
| const createdDateBefore = format(new Date(), "yyyy-MM-dd"); | ||
| await page.goto( | ||
| `/facility/${facilityId}/encounters/patients/all?created_date_after=${createdDateAfter}&created_date_before=${createdDateBefore}&status=in_progress`, | ||
| ); | ||
| await page.getByText("View Encounter").first().click(); | ||
| }); |
There was a problem hiding this comment.
Verify encounter availability before interaction.
The test navigates to an encounter list and clicks the first "View Encounter" link without verifying that any encounters exist. If the filtered list is empty, the test will fail at line 38.
Recommended verification
Add a check to ensure at least one encounter is available:
await page.goto(
`/facility/${facilityId}/encounters/patients/all?created_date_after=${createdDateAfter}&created_date_before=${createdDateBefore}&status=in_progress`,
);
+ const encounterLink = page.getByText("View Encounter").first();
+ await expect(encounterLink).toBeVisible({ timeout: 10000 });
- await page.getByText("View Encounter").first().click();
+ await encounterLink.click();This ensures the test fails gracefully with a clear timeout message if no encounters are available, rather than failing with an obscure "element not found" error.
🤖 Prompt for AI Agents
In @tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts around lines
29 - 39, Before calling page.getByText("View Encounter").first().click() in the
test.beforeEach block, verify at least one "View Encounter" element exists and
is visible; for example, obtain the locator for page.getByText("View
Encounter"), wait for it to be visible or assert its count is > 0 (so the test
fails with a clear timeout if no encounters are present) before proceeding to
click the first one.
| test.afterEach(async ({ page }) => { | ||
| await test.step("Cleanup: Remove added member", async () => { | ||
| try { | ||
| const dialog = page.getByRole("dialog", { name: "Manage Care Team" }); | ||
|
|
||
| const isDialogVisible = await dialog.isVisible().catch(() => false); | ||
| if (!isDialogVisible) { | ||
| return; | ||
| } | ||
|
|
||
| const removableMembers = dialog | ||
| .locator("button") | ||
| .filter({ has: page.locator("svg.lucide-x") }); | ||
| const removableCount = await removableMembers.count(); | ||
|
|
||
| if (removableCount === 0) { | ||
| return; | ||
| } | ||
|
|
||
| const removeButton = removableMembers.last(); | ||
| await removeButton.click(); | ||
| await page.getByRole("button", { name: "Remove" }).click(); | ||
| await expectToast(page, /removed successfully/i); | ||
| } catch { | ||
| // Member might already be removed or not added | ||
| } | ||
| }); | ||
| }); |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Enhance cleanup robustness by reopening dialog if needed.
The cleanup logic returns early if the dialog isn't visible (line 48-50), which could leave added members in place if a test fails after adding a member but before the assertion phase. Consider reopening the dialog to ensure cleanup always runs.
More robust cleanup approach
test.afterEach(async ({ page }) => {
await test.step("Cleanup: Remove added member", async () => {
try {
const dialog = page.getByRole("dialog", { name: "Manage Care Team" });
const isDialogVisible = await dialog.isVisible().catch(() => false);
if (!isDialogVisible) {
- return;
+ // Reopen dialog for cleanup
+ await openCareTeamDialog(page);
}
const removableMembers = dialog
.locator("button")
.filter({ has: page.locator("svg.lucide-x") });
const removableCount = await removableMembers.count();
if (removableCount === 0) {
return;
}
const removeButton = removableMembers.last();
await removeButton.click();
await page.getByRole("button", { name: "Remove" }).click();
await expectToast(page, /removed successfully/i);
} catch {
// Member might already be removed or not added
}
});
});Committable suggestion skipped: line range outside the PR's diff.
| test("Closing without clicking Add does not save care team member", async ({ | ||
| page, | ||
| }) => { | ||
| await test.step("Open care team sheet", async () => { | ||
| await openCareTeamDialog(page); | ||
| await expect(page.getByText("Administration")).toBeVisible(); | ||
| }); | ||
|
|
||
| await test.step("Select member and role without adding", async () => { | ||
| const memberSelector = page | ||
| .getByRole("combobox") | ||
| .filter({ hasText: "Select Member" }); | ||
| await expect(memberSelector).toBeEnabled(); | ||
| await memberSelector.click(); | ||
| await page.getByPlaceholder("Search").fill(selectedUsername); | ||
| await page.getByText(selectedUsername).click(); | ||
|
|
||
| await page | ||
| .getByRole("combobox") | ||
| .filter({ hasText: "Select Role" }) | ||
| .click(); | ||
| await page.getByPlaceholder("Select Role").fill(selectedRole); | ||
| await page.getByRole("option", { name: selectedRole }).click(); | ||
| }); | ||
|
|
||
| await test.step("Close sheet without clicking Add", async () => { | ||
| await page.getByRole("button", { name: "Close" }).click(); | ||
| await expect( | ||
| page.getByRole("dialog", { name: "Manage Care Team" }), | ||
| ).not.toBeVisible(); | ||
| }); | ||
|
|
||
| await test.step("Verify member was not added", async () => { | ||
| await openCareTeamDialog(page); | ||
|
|
||
| const dialog = page.getByRole("dialog", { name: "Manage Care Team" }); | ||
| await expect(dialog.getByText(selectedUsername)).not.toBeVisible(); | ||
| await expect(dialog.getByText(selectedRole)).not.toBeVisible(); | ||
| }); | ||
| }); |
There was a problem hiding this comment.
Potential false negative in verification logic.
Lines 207-208 verify that the member wasn't added by checking that selectedUsername and selectedRole are not visible in the dialog. However, if other care team members share the same username or role, these assertions could fail even though the test correctly didn't add the member.
Consider more specific verification, such as checking that the member count hasn't increased, or verifying the absence of a specific combination rather than individual text strings. Alternatively, if you know the initial state, you could compare before/after states:
await test.step("Verify member was not added", async () => {
await openCareTeamDialog(page);
const dialog = page.getByRole("dialog", { name: "Manage Care Team" });
const members = dialog.locator("button").filter({ has: page.locator("svg.lucide-x") });
const memberCount = await members.count();
// Verify count matches initial state (would need to capture initial count in beforeEach)
await expect(memberCount).toBe(expectedInitialCount);
});🤖 Prompt for AI Agents
In @tests/facility/patient/encounter/careTeam/linkCareTeam.spec.ts around lines
171 - 210, The verification is brittle because asserting
dialog.getByText(selectedUsername) and dialog.getByText(selectedRole) can
produce false negatives if other members share those strings; instead update the
"Verify member was not added" step in this test to assert a more specific
condition such as (a) capture the initial member count before the add attempt
(using the dialog locator returned by openCareTeamDialog or the same
dialog.getByRole("dialog", { name: "Manage Care Team" })) and assert the count
unchanged after closing, or (b) assert absence of a specific member row that
combines both selectedUsername and selectedRole (e.g., locate a row/button that
contains both values) so you check the composite entry rather than individual
text nodes; use the existing selectedUsername/selectedRole and the dialog
locator to implement this change.
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.