-
Notifications
You must be signed in to change notification settings - Fork 532
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
patient registration in multiple combination #10287
Conversation
WalkthroughThis pull request introduces comprehensive changes across multiple Cypress test files and related components, focusing on streamlining test setup processes, enhancing patient registration functionality, and improving test structure. The modifications primarily involve consolidating login processes into Changes
Sequence DiagramsequenceDiagram
participant Test as Cypress Test
participant Login as Login Command
participant Page as Patient Registration Page
Test->>Login: Invoke loginByApi
Login->>Page: Navigate to root URL
Login-->>Test: Authenticate user
Test->>Page: Visit page
Test->>Page: Fill patient details
Test->>Page: Submit registration
Page-->>Test: Verify patient creation
Possibly related PRs
Suggested Labels
Suggested Reviewers
Poem
✨ Finishing Touches
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
✅ Deploy Preview for care-ohc ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
Deploying care-fe with Cloudflare Pages
|
CARE Run #4482
Run Properties:
|
Project |
CARE
|
Branch Review |
cypress-patientregistration
|
Run status |
Passed #4482
|
Run duration | 05m 23s |
Commit |
4b4bf67112: patient registration in multiple combination
|
Committer | Mohammed Nihal |
View all properties for this run ↗︎ |
Test results | |
---|---|
Failures |
0
|
Flaky |
0
|
Pending |
0
|
Skipped |
0
|
Passing |
9
|
View all changes introduced in this branch ↗︎ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 4
🧹 Nitpick comments (5)
cypress/support/commands.ts (1)
6-7
: Leveragecy.session
for streamlined login flow.Migrating from local storage reliance to
cy.session
is a recommended Cypress practice. It simplifies authentication handling by automatically caching sessions and reduces repeated login flows. The additional post-login check (asserting the URL doesn’t include/login
) ensures the login was indeed successful.A potential enhancement is to incorporate a check for valid user data (e.g., verifying server responses) before confirming the session is ready.
Also applies to: 18-18
cypress/pageObject/Patients/PatientCreation.ts (1)
26-27
: Consider validations for region-specific fields.
state
anddistrict
properties are newly introduced. If the application is region-specific, ensure these fields are validated against a known reference. Otherwise, consider a fallback or “Other” option for unknown states/districts.cypress/e2e/patient_spec/patient_encounter.cy.ts (1)
13-14
: Consider removing duplicate login calls.Since the user is already logged in at
before
, callingloginByApi("devnurse")
again inbeforeEach
might be redundant. If multiple test cases require re-initialization, a forced session refresh can be done, but do confirm necessity before doubling the login calls.cypress/utils/commonUtils.ts (1)
Line range hint
49-74
: Add input validation for address generation.While the multi-line address support is a good addition, the function could benefit from input validation and proper string sanitization.
Consider these improvements:
export function generateAddress(multiLine: boolean = false): string { + // Validate input + if (typeof multiLine !== 'boolean') { + throw new TypeError('multiLine parameter must be a boolean'); + } + const houseNumbers = ["123", "45A", "67B", "89", "234"]; const apartments = ["Apt 4B", "Unit 12", "Flat 3A", "Suite 7", "#15"]; const streets = [ "Main Street", "Park Avenue", "Oak Road", "Church Street", "Hill Road", ]; const areas = [ "Downtown", "Westside", "North Colony", "South Extension", "East End", ]; const randomHouse = houseNumbers[getRandomIndex(houseNumbers.length)]; const randomApt = apartments[getRandomIndex(apartments.length)]; const randomStreet = streets[getRandomIndex(streets.length)]; const randomArea = areas[getRandomIndex(areas.length)]; + // Sanitize components to prevent injection + const sanitize = (str: string) => str.replace(/[<>]/g, ''); + return multiLine - ? `${randomHouse} ${randomStreet}\n${randomApt}\n${randomArea}` - : `${randomHouse}, ${randomStreet}, ${randomArea}`; + ? `${sanitize(randomHouse)} ${sanitize(randomStreet)}\n${sanitize(randomApt)}\n${sanitize(randomArea)}` + : `${sanitize(randomHouse)}, ${sanitize(randomStreet)}, ${sanitize(randomArea)}`; }cypress/e2e/patient_spec/patient_creation.cy.ts (1)
28-35
: Consider extracting basePatientData to a separate test data file.The base patient data could be moved to a separate file to improve maintainability and reusability across different test files.
Create a new file
cypress/fixtures/patientTestData.ts
:export const basePatientData: Partial<PatientFormData> = { pincode: "682001", state: "Kerala", district: "Ernakulam", localBody: "Aluva", ward: "4", sameAsPermanentAddress: true, hasEmergencyContact: false, };
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (9)
cypress/e2e/facility_spec/facility_creation.cy.ts
(1 hunks)cypress/e2e/patient_spec/patient_creation.cy.ts
(2 hunks)cypress/e2e/patient_spec/patient_encounter.cy.ts
(1 hunks)cypress/e2e/users_spec/user_creation.cy.ts
(1 hunks)cypress/pageObject/Patients/PatientCreation.ts
(6 hunks)cypress/support/commands.ts
(1 hunks)cypress/support/index.ts
(0 hunks)cypress/utils/commonUtils.ts
(2 hunks)src/components/Patient/PatientRegistration.tsx
(1 hunks)
💤 Files with no reviewable changes (1)
- cypress/support/index.ts
✅ Files skipped from review due to trivial changes (1)
- src/components/Patient/PatientRegistration.tsx
🧰 Additional context used
📓 Learnings (1)
cypress/e2e/facility_spec/facility_creation.cy.ts (2)
Learnt from: Jacobjeevan
PR: ohcnetwork/care_fe#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: kihan2518B
PR: ohcnetwork/care_fe#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.
⏰ Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: cypress-run (1)
🔇 Additional comments (13)
cypress/support/commands.ts (2)
4-4
: Use dynamic session naming for easier debugging.Defining the session name based on the user role is a good approach for isolating cached session data, which helps improve test maintainability and debugging.
21-21
: No additional changes or issues identified.cypress/pageObject/Patients/PatientCreation.ts (9)
4-14
: Strongly typed enums for patient data.Using string literal unions for
gender
andbloodGroup
ensures better type-safety across the codebase. Converting them to TypeScript enums or a separate constants file could further centralize these definitions if they are reused in multiple places.
16-17
: Optional fields improve flexibility.Allowing
dateOfBirth
orage
(instead of requiring both) and introducing address/contact checkboxes provide a robust data model. Just ensure that form validations are in place to avoid partial or invalid data, especially for emergency contact details.Also applies to: 19-22
37-56
: Selector naming is consistent.The choice of data-cy attributes and naming conventions is consistent and descriptive. This helps maintain stable locators for Cypress tests.
81-81
: Verifying content presence with partial matches.Using
cy.verifyContentPresence()
withObject.values()
ensures coverage for relevant text in search results. Confirm that no extraneous fields appear in search results, as partial matches could pass inadvertently.
90-90
: Improved data entry methods.These lines streamline data entry for patient attributes (name, phone number, DOB, gender, blood group, address, pincode). The typed approach clarifies test intent and improves reliability. Just ensure that errors (e.g., invalid phone format) are handled or tested separately.
Also applies to: 95-95, 105-107, 114-116, 121-121, 126-126, 131-131
135-174
: Comprehensive patient details workflow.
- Conditional handling of DOB or age prevents conflicting data sets.
- Toggling permanent address vs. current address (lines 149-156) is well-structured.
- Emergency contact logic (lines 157-167) covers both enabling and disabling the field.
- The final block chaining for pincode/state/district/ward ensures a single cohesive flow.
Perform thorough testing, especially around date/age edge cases and defaulting to
sameAsPermanentAddress = true
if not specified.
178-178
: Location dropdown methods.Using
typeAndSelectOption
is a good approach for dynamic dropdowns. Just make sure it handles special characters or synonyms that might appear in local bodies and wards.Also applies to: 183-183
201-212
: New address & emergency contact methods.Implementing separate helpers (
enterPermanentAddress
andenterEmergencyPhone
) keeps the code modular. Validate edge cases such as blank addresses or phone numbers.
214-221
: Conditional state/district selection ensures minimal re-typing.Skipping re-selection if values match the existing dropdown is an excellent performance optimization. Confirm that re-selection logic is correct when updating from an already-filled field.
Also applies to: 223-230
cypress/e2e/patient_spec/patient_encounter.cy.ts (1)
8-10
: Single login before tests.Moving the
loginByApi("devnurse")
call into thebefore
hook ensures that the session is established only once and persists across the suite. This reduces repeated login overhead and speeds up the tests.cypress/e2e/patient_spec/patient_creation.cy.ts (1)
111-137
: Great test coverage for diverse patient scenarios!The test cases effectively cover various patient types and scenarios, including non-binary, transgender, and different address combinations. This aligns well with the PR objective of handling multiple patient registration combinations.
@nihal467 Your efforts have helped advance digital healthcare and TeleICU systems. 🚀 Thank you for taking the time out to make CARE better. We hope you continue to innovate and contribute; your impact is immense! 🙌 |
Proposed Changes
@ohcnetwork/care-fe-code-reviewers
Merge Checklist
Summary by CodeRabbit
Release Notes
Testing Improvements
Patient Registration
Utility Enhancements