# 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

```javascript
// 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