simrsx-fe/QUICK_START_TESTING.md

QUICK START - ENCOUNTER EDIT MODE TESTING

Pre-Test Checklist

• You have valid encounter IDs to test with
• Browser DevTools are ready (F12 or Cmd+Opt+I)
• Network tab can be monitored
• You have update permissions (RBAC configured)
• API is running and accessible

---

Running TEST 1: Load Edit Page (5 min)

Setup

1. Open browser DevTools → Console tab
2. Navigate to: http://localhost:3000/outpatient/encounter/123/edit (replace 123 with valid ID)

Expected Flow

1. Page loads with spinner
2. Console shows: 📥 [EDIT MODE] Loading encounter detail: {id: 123}
3. After 1-2 seconds, data loads
4. Console shows: ✅ [EDIT MODE] Encounter detail loaded and form mapped successfully
5. Form fields auto-populate with encounter data

Verify

• Patient name visible in form
• Doctor/Specialist selected
• Date in YYYY-MM-DD format
• Payment type shown (jkn, spm, etc.)
• If JKN payment: Card number and SEP number visible
• No console errors (❌ should not appear)
• No red validation error messages

Success Criteria

✅ Form fully populated and no errors

---

Running TEST 2: Edit & Save (5 min)

Setup

• Use same page from TEST 1 (form already populated)
• Open Network tab and filter: encounter

Steps

1. Change doctor to different one
2. Click "Simpan" (Save) button
3. Watch Network tab for PATCH request
4. Watch Console for save logs

Expected Flow

1. Click save
2. Console shows: 💾 [EDIT MODE] Sending PATCH request: {id: 123, payload: {...}}
3. Network shows: PATCH /api/v1/encounter/123
4. After 1-2 seconds: Console shows: 📤 [SAVE] API Response: {success: true}
5. Console shows: ✅ [SAVE] Success - Redirecting to list page
6. Page navigates to list

Verify Network Tab

Click on the PATCH request and check:

• URL: /api/v1/encounter/123 (correct ID)
• Method: PATCH (not PUT or POST)
• Headers: Content-Type: application/json
• Payload (Request body):
  • appointment_doctor_code is string
  • registeredAt has ISO format with Z
  • paymentMethod_code matches payment type
• Response: "success": true

Success Criteria

✅ PATCH request sent and success toast shown

---

Running TEST 3: BPJS Conditional Fields (3 min)

Setup

• Navigate to new edit page: /outpatient/encounter/456/edit
• Form loads with SPM payment type
• Card number field is hidden/empty

Steps

1. Find the "Jenis Pembayaran" (Payment Type) dropdown
2. Change from SPM to JKN
3. Observe form changes

Expected Behavior

• Card number field appears and required
• SEP type field appears and required
• SEP number field appears (if SEP type selected)
• Try to save without card number
• Validation error appears: "No. Kartu BPJS wajib diisi"

Fill Fields

1. Enter BPJS card number (e.g., 0000123456789)
2. Select SEP type
3. Try to save again
4. Now validation should pass

Success Criteria

✅ Conditional fields work and validation enforces requirements

---

Running TEST 4: Error Handling (5 min)

Setup (Simulate Error)

• Open DevTools
• Go to Network tab
• Find "Throttling" dropdown (set to "Slow 3G" or "Offline")

Scenario A: GET Failure

1. Set network to Offline
2. Navigate to edit page: /outpatient/encounter/789/edit
3. Observe error handling

Expected Result

• Error toast appears: "Gagal memuat data kunjungan"
• Console shows: ❌ [EDIT MODE] Failed to load encounter
• Page auto-redirects to list

Scenario B: PATCH Failure

1. Load page normally (turn network back on)
2. Set network to Offline
3. Try to save changes
4. Observe error handling

Expected Result

• Error toast appears: "Gagal memperbarui kunjungan"
• Console shows: ❌ [SAVE] Failed
• Page stays on form (user can retry)
• Turn network back on and retry save

Success Criteria

✅ Error handling works correctly for both GET and PATCH

---

Running TEST 5: Data Types (3 min)

Verify in Browser Console

// 1. Check form object structure
// Go to any edit page, then in console:
window.__nuxt__ // If available

// 2. Check Network tab for PATCH payload
// Look at "Request body" for PATCH /api/v1/encounter/{id}

Manual Checks

Doctor ID Type:

• Form shows: "Dr. John Doe" (human readable)
• Network payload shows: "appointment_doctor_code": "5" (string)
• ✅ Correct

Date Format:

• Form shows: "2025-12-02" (YYYY-MM-DD)
• Network payload shows: "registeredAt": "2025-12-02T10:30:00.000Z" (ISO)
• ✅ Correct

Payment Type:

• Form shows: "BPJS" (human readable)
• Form value: "jkn" (code)
• Network payload shows: "paymentMethod_code": "insurance" (API code)
• ✅ Correct

Success Criteria

✅ All type conversions transparent and correct

---

Console Log Reference

Good Logs (No Issues)

✅ [EDIT MODE] Encounter detail loaded and form mapped successfully
✅ [SAVE] Success - Redirecting to list page
📥 [EDIT MODE] Loading encounter detail: {id: 123}
📋 [EDIT MODE] Mapped encounter to form: {...}
💾 [EDIT MODE] Sending PATCH request: {id: 123, payload: {...}}
📤 [SAVE] API Response: {success: true}

Bad Logs (Issues Found)

❌ [EDIT MODE] Failed to load encounter: 'Encounter not found'
❌ [SAVE] Failed: 'Validation error: invalid doctor_id'
❌ [SAVE] Error saving encounter: Error: Failed to put encounter

Action: If you see ❌, note the exact error and check troubleshooting guide

---

Common Issues During Testing

Problem	Cause	Solution
Form not populated	API call failed	Check Network tab, verify API is running
Save button disabled	Validation fails	Check form for required fields marked in red
PATCH shows 422	Invalid data type	Check Network payload vs expected schema
Doctor list empty	Specialist not selected	Select specialist first
Date shows wrong format	Conversion failed	Check console for mapping logs

---

Quick Reference: Test URLs

Outpatient Tests

http://localhost:3000/outpatient/encounter/1/edit
http://localhost:3000/outpatient/encounter/2/edit
http://localhost:3000/outpatient/encounter/3/edit

Inpatient Tests

http://localhost:3000/inpatient/encounter/1/edit
http://localhost:3000/inpatient/encounter/2/edit

Emergency Tests

http://localhost:3000/emergency/encounter/1/edit
http://localhost:3000/emergency/encounter/2/edit

---

Testing Checklist Summary

TEST 1 - Load Edit Page

• Form loads without errors
• All fields populated
• Console shows success logs
• Time: 5 min

TEST 2 - Edit & Save

• Edit values
• PATCH request sent correctly
• Success message shown
• Navigates to list
• Time: 5 min

TEST 3 - BPJS Fields

• Conditional fields appear
• Validation enforced
• Save blocked without required fields
• Time: 3 min

TEST 4 - Error Handling

• GET errors handled correctly
• PATCH errors handled correctly
• User feedback appropriate
• Time: 5 min

TEST 5 - Data Types

• Doctor ID: string
• Dates: ISO format with Z
• Payment type: correct mapping
• Time: 3 min

Total Time: ~21 minutes

---

Success Indicators

All Tests Pass When:

✅ No ❌ in console logs
✅ All form fields populate correctly
✅ PATCH requests appear in Network tab
✅ Success toasts show after save
✅ Redirects work properly
✅ Validation enforces requirements
✅ Error messages are helpful
✅ Data types match expectations

---

Report Issues

If you encounter issues:

1. Take a screenshot of the error
2. Copy console logs (search for ❌ patterns)
3. Check Network tab for failed requests
4. Note the encounter ID and feature type (outpatient/inpatient/emergency)
5. Describe what you were doing when issue occurred

---

Next Steps After Testing

If all tests pass:

1. ✅ Feature is ready for deployment
2. ✅ Can proceed to detail/readonly pages
3. ✅ Can implement additional features

If issues found:

1. Document the issue with error logs
2. Check troubleshooting in ENCOUNTER_EDIT_TEST.md
3. Review data mapping in ENCOUNTER_API_REFERENCE.md
4. Check handler implementation in encounter-entry.handler.ts

---

Good Luck with Testing! 🚀

For more details, refer to:

• ENCOUNTER_EDIT_TEST.md - Full test guide with detailed steps
• ENCOUNTER_API_REFERENCE.md - API and handler reference
• IMPLEMENTATION_SUMMARY.md - Overall architecture overview