130 lines
3.9 KiB
Markdown
130 lines
3.9 KiB
Markdown
# CLQMS Task Completion Guidelines
|
|
|
|
## When a Task is Completed
|
|
|
|
### 1. Run Tests
|
|
Always run relevant tests after making changes:
|
|
|
|
```bash
|
|
# Run all tests
|
|
./vendor/bin/phpunit
|
|
|
|
# Run specific test file
|
|
./vendor/bin/phpunit tests/feature/Patients/PatientCreateTest.php
|
|
|
|
# Run specific test method
|
|
./vendor/bin/phpunit --filter testCreatePatientSuccess tests/feature/Patients/PatientCreateTest.php
|
|
```
|
|
|
|
### 2. Verify Code Quality
|
|
|
|
#### Check for Syntax Errors
|
|
```bash
|
|
php -l app/Controllers/Patient/PatientController.php
|
|
```
|
|
|
|
#### Check Test Results
|
|
Ensure:
|
|
- All existing tests still pass
|
|
- New tests (if any) pass
|
|
- No unexpected warnings or errors
|
|
|
|
### 3. Code Review Checklist
|
|
|
|
#### Controller Changes
|
|
- [ ] Validation rules are properly defined
|
|
- [ ] Error handling uses try-catch blocks
|
|
- [ ] Responses use standardized format with `ResponseTrait`
|
|
- [ ] Authentication filter applied where needed
|
|
- [ ] Input sanitization via validation rules
|
|
- [ ] Database operations wrapped in transactions (if multi-table)
|
|
|
|
#### Model Changes
|
|
- [ ] Extends `BaseModel` for UTC handling
|
|
- [ ] Table name, primary key, allowed fields defined
|
|
- [ ] Uses `checkDbError()` for error detection
|
|
- [ ] Audit logging via `AuditService::logData()` for data changes
|
|
- [ ] Soft delete fields configured if using soft deletes
|
|
- [ ] Nested data properly handled (extracted before filtering)
|
|
|
|
#### New Routes
|
|
- [ ] Added to `app/Config/Routes.php`
|
|
- [ ] Follows REST conventions (GET, POST, PATCH, DELETE)
|
|
- [ ] Grouped appropriately under `/api/`
|
|
- [ ] Auth filter applied if needed
|
|
|
|
#### New Tests
|
|
- [ ] Test name follows `test<Action><Scenario><ExpectedResult>` pattern
|
|
- [ ] Uses `FeatureTestTrait`
|
|
- [ ] Uses `Factory::create('id_ID')` for Indonesian test data
|
|
- [ ] Asserts correct status codes (200, 201, 400, 401, 404, 500)
|
|
- [ ] Tests both success and failure scenarios
|
|
|
|
### 4. Common Issues to Check
|
|
|
|
#### Database Operations
|
|
- Multi-table operations should use transactions
|
|
- Use parameterized queries (Query Builder handles this)
|
|
- Check for empty/null arrays before processing
|
|
|
|
#### Nested Data
|
|
- Extract nested arrays before filtering/processing
|
|
- Handle empty/null nested data appropriately
|
|
- Use transactions for multi-table operations
|
|
|
|
#### Date Handling
|
|
- All dates stored in UTC
|
|
- Use `helper('utc')` for conversions
|
|
- BaseModel extends with automatic UTC conversion
|
|
|
|
#### Security
|
|
- Input validation rules defined
|
|
- SQL injection prevention via parameterized queries
|
|
- JWT validation on protected endpoints
|
|
- No sensitive data logged or exposed
|
|
|
|
### 5. What NOT to Do
|
|
|
|
- **Do NOT commit** unless explicitly asked by the user
|
|
- **Do NOT push** to remote repository unless asked
|
|
- **Do NOT** skip running tests
|
|
- **Do NOT** add comments unless specifically requested
|
|
- **Do NOT** modify `.env` (database credentials, secrets)
|
|
- **Do NOT** include hardcoded secrets in code
|
|
|
|
### 6. Common Test Status Codes Reference
|
|
|
|
| Code | Usage | Example |
|
|
|------|-------|---------|
|
|
| 200 | GET/PATCH success | `->assertStatus(200)` |
|
|
| 201 | POST success (created) | `->assertStatus(201)` |
|
|
| 400 | Validation error | `->assertStatus(400)` |
|
|
| 401 | Unauthorized | `->assertStatus(401)` |
|
|
| 404 | Not found | `->assertStatus(404)` |
|
|
| 500 | Server error | `->assertStatus(500)` |
|
|
|
|
### 7. After Completing Tasks
|
|
|
|
Simply inform the user the task is complete. For example:
|
|
```
|
|
Task completed. The patient create endpoint now validates the identifier type dynamically.
|
|
```
|
|
|
|
Or if tests were run:
|
|
```
|
|
Task completed. All tests passing:
|
|
- testCreatePatientSuccess ✓
|
|
- testCreatePatientValidationFail ✓
|
|
```
|
|
|
|
### 8. When Something Goes Wrong
|
|
|
|
If tests fail or errors occur:
|
|
1. Check the error message carefully
|
|
2. Review the code against the patterns in this guide
|
|
3. Check database connection and configuration
|
|
4. Verify all required dependencies are installed
|
|
5. Review log files in `writable/logs/`
|
|
|
|
If unable to resolve, inform the user with details of the issue.
|