Files
daily-notification-plugin/docs/alarms/PHASE2-VERIFICATION.md
Matthew Raymer c8a3906449 docs(test): add Phase 2 force stop recovery testing infrastructure
Adds documentation and test harness for Phase 2 (Force Stop Detection & Recovery).

Changes:
- Add PHASE2-EMULATOR-TESTING.md with detailed test procedures
- Add PHASE2-VERIFICATION.md with test matrix and verification template
- Add test-phase2.sh automated test harness

Test harness features:
- 3 test cases: force stop with cleared alarms, intact alarms, empty DB
- Automatic force stop simulation via adb
- Log parsing for scenario detection and recovery results
- UI prompts for plugin configuration and scheduling

Related:
- Directive: android-implementation-directive-phase2.md
- Requirements: docs/alarms/03-plugin-requirements.md §3.1.4
- Testing: docs/alarms/PHASE2-EMULATOR-TESTING.md
- Verification: docs/alarms/PHASE2-VERIFICATION.md
2025-11-27 10:01:40 +00:00

196 lines
6.3 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# Phase 2 Force Stop Recovery Verification
**Plugin:** Daily Notification Plugin
**Scope:** Force stop detection & recovery (App ID: `com.timesafari.dailynotification`)
**Related Docs:**
- `android-implementation-directive-phase2.md`
- `03-plugin-requirements.md` (Force Stop & App Termination behavior)
- `PHASE2-EMULATOR-TESTING.md`
- `000-UNIFIED-ALARM-DIRECTIVE.md`
---
## 1. Objective
Phase 2 verifies that the Daily Notification Plugin:
1. Correctly detects **force stop** conditions where alarms may have been cleared.
2. **Reschedules** future notifications when schedules exist in the database but alarms are missing.
3. **Avoids heavy recovery** when alarms are intact (no false positives).
4. **Does not misfire** force-stop recovery on first launch / empty database.
Phase 2 builds on Phase 1, which already covers:
- Cold start detection
- Missed notification marking
- Basic alarm verification
---
## 2. Test Method
Verification is performed using the emulator test harness:
```bash
cd test-apps/android-test-app
./test-phase2.sh
```
This script:
* Builds and installs the debug APK (`app/build/outputs/apk/debug/app-debug.apk`).
* Guides the tester through UI steps for scheduling notifications and configuring the plugin.
* Simulates:
* `force-stop` behavior via `adb shell am force-stop ...`
* "Soft stop" / process kill via `adb shell am kill ...`
* First launch / empty DB via uninstall + reinstall
* Collects and parses `DNP-REACTIVATION` log lines, extracting:
* `scenario`
* `missed`
* `rescheduled`
* `verified`
* `errors`
Detailed steps and expectations are documented in `PHASE2-EMULATOR-TESTING.md`.
---
## 3. Test Matrix
| ID | Scenario | Method / Script Step | Expected Behavior | Result | Notes |
| --- | ---------------------------------------------- | ------------------------------------------------------ | ------------------------------------------------------------------------------------------------------ | ------ | ----- |
| 2.1 | Force stop clears alarms | `test-phase2.sh` TEST 1: Force Stop Alarms Cleared | `scenario=FORCE_STOP`, `rescheduled>0`, `errors=0` | ☐ | |
| 2.2 | Force stop / process stop with alarms intact | `test-phase2.sh` TEST 2: Soft Stop Alarms Intact | `scenario != FORCE_STOP`, `rescheduled=0`, `errors=0` | ☐ | |
| 2.3 | First launch / empty DB (no schedules present) | `test-phase2.sh` TEST 3: First Launch / No Schedules | Either no recovery logs **or** `scenario=NONE` (or equivalent) and `rescheduled=0`, `errors=0` | ☐ | |
> Fill in **Result** and **Notes** after executing the script on your baseline emulator/device.
---
## 4. Expected Log Patterns
### 4.1 Force Stop Alarms Cleared (Test 2.1)
Typical expected `DNP-REACTIVATION` log patterns:
```text
DNP-REACTIVATION: Detected scenario: FORCE_STOP
DNP-REACTIVATION: Rescheduled alarm: daily_<id> for <time>
DNP-REACTIVATION: Rescheduled missing alarm: daily_<id> at <time>
DNP-REACTIVATION: Force stop recovery completed: missed=1, rescheduled=1, verified=0, errors=0
```
The **script** will report:
```text
✅ TEST 1 PASSED: Force stop detected and alarms rescheduled (scenario=FORCE_STOP, rescheduled=1).
```
### 4.2 Soft Stop Alarms Intact (Test 2.2)
Typical expected patterns:
```text
DNP-REACTIVATION: Detected scenario: COLD_START
DNP-REACTIVATION: Cold start recovery completed: missed=0, rescheduled=0, verified>=0, errors=0
```
The script should **not** treat this as a force-stop recovery:
```text
✅ TEST 2 PASSED: No heavy force-stop recovery when alarms are intact (scenario=COLD_START, rescheduled=0).
```
(Adjust `scenario` name to match your actual implementation.)
### 4.3 First Launch / Empty DB (Test 2.3)
Two acceptable patterns:
1. **No recovery logs at all** (`DNP-REACTIVATION` absent), or
2. Explicit "no schedules" scenario, e.g.:
```text
DNP-REACTIVATION: No schedules present — skipping recovery (first launch)
```
or
```text
DNP-REACTIVATION: Detected scenario: NONE
```
Script-level success message might be:
```text
✅ TEST 3 PASSED: NONE scenario detected with no rescheduling.
```
or:
```text
✅ TEST 3 PASSED: No recovery logs when there are no schedules (safe behavior).
```
---
## 5. Latest Known Good Run (Emulator) Placeholder
> Update this section after your first successful run.
**Environment**
* Device: Pixel 8 API 34 (Android 14)
* App ID: `com.timesafari.dailynotification`
* Build: Debug `app-debug.apk` from commit `<GIT_HASH>`
* Script: `./test-phase2.sh`
* Date: 2025-11-XX
**Observed Results**
***2.1 Force Stop / Alarms Cleared**
* `scenario=FORCE_STOP`
* `missed=1, rescheduled=1, verified=0, errors=0`
***2.2 Soft Stop / Alarms Intact**
* `scenario=COLD_START` (or equivalent non-force-stop scenario)
* `rescheduled=0, errors=0`
***2.3 First Launch / Empty DB**
* `scenario=NONE` (or no logs)
* `rescheduled=0, errors=0`
**Conclusion:**
> To be filled after first successful emulator run.
---
## 6. Overall Status
> To be updated once the first emulator pass is complete.
* **Implementation Status:** ☐ Pending / ✅ Implemented in `ReactivationManager` (Android plugin)
* **Test Harness:** ✅ `test-phase2.sh` in `test-apps/android-test-app`
* **Emulator Verification:** ☐ Pending / ✅ Completed (update when done)
Once all boxes are checked:
> **Overall Status:** ✅ **VERIFIED** Phase 2 behavior is implemented, emulator-tested, and aligned with `03-plugin-requirements.md` and `android-implementation-directive-phase2.md`.
---
## 7. Related Documentation
- [Phase 2 Directive](../android-implementation-directive-phase2.md) - Implementation details
- [Phase 2 Emulator Testing](./PHASE2-EMULATOR-TESTING.md) - Test procedures
- [Phase 1 Verification](./PHASE1-VERIFICATION.md) - Prerequisite verification
- [Plugin Requirements](./03-plugin-requirements.md) - Requirements this phase implements
- [Platform Capability Reference](./01-platform-capability-reference.md) - OS-level facts
---
**Status**: ☐ **PENDING** Phase 2 implementation and testing pending
**Last Updated**: November 2025