trent_larson/daily-notification-plugin
4
0
Fork 0
Code Issues Pull Requests 2 Projects Releases Wiki Activity
Files
945956dc5a0c330b351ce900ae999ac33b61aa8f
daily-notification-plugin/docs/alarms/PHASE3-VERIFICATION.md
Matthew Raymer 28fb233286 docs(test): add Phase 3 boot recovery testing infrastructure 
Adds documentation and test harness for Phase 3 (Boot-Time Recovery).

Changes:
- Update android-implementation-directive-phase3.md with concise boot recovery flow
- Add PHASE3-EMULATOR-TESTING.md with detailed test procedures
- Add PHASE3-VERIFICATION.md with test matrix and verification template
- Add test-phase3.sh automated test harness

Test harness features:
- 4 test cases: future alarms, past alarms, no schedules, silent recovery
- Automatic emulator reboot handling
- Log parsing for boot recovery scenario and results
- UI prompts for plugin configuration and scheduling
- Verifies silent recovery without app launch

Related:
- Directive: android-implementation-directive-phase3.md
- Requirements: docs/alarms/03-plugin-requirements.md §3.1.1
- Testing: docs/alarms/PHASE3-EMULATOR-TESTING.md
- Verification: docs/alarms/PHASE3-VERIFICATION.md
2025-11-27 10:01:46 +00:00

202 lines
6.9 KiB
Markdown
Raw 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 3 – Boot-Time Recovery Verification
**Plugin:** Daily Notification Plugin
**Scope:** Boot-Time Recovery (Recreate Alarms After Reboot)
**Related Docs:**
- `android-implementation-directive-phase3.md`
- `PHASE3-EMULATOR-TESTING.md`
- `test-phase3.sh`
- `000-UNIFIED-ALARM-DIRECTIVE.md`
---
## 1. Objective
Phase 3 confirms that the Daily Notification Plugin:
1. Reconstructs all daily notification alarms after a **full device reboot**.
2. Correctly handles **past** vs **future** schedules:
- Past: mark as missed, schedule next occurrence
- Future: simply recreate alarms
3. Handles **empty DB / no schedules** without misfiring recovery.
4. Performs **silent boot recovery** (no app launch required) when schedules exist.
5. Logs a consistent, machine-readable summary:
- `scenario`
- `missed`
- `rescheduled`
- `verified`
- `errors`
Verification is performed via the emulator harness:
```bash
cd test-apps/android-test-app
./test-phase3.sh
```
---
## 2. Test Matrix (From Script)
| ID | Scenario | Script Test | Expected Behavior | Result | Notes |
| --- | --------------------------------------- | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------ | ------ | ----- |
| 3.1 | Boot with Future Alarms | TEST 1 – Boot with Future Alarms | `scenario=BOOT`, `rescheduled>0`, `errors=0`; alarms present after boot | ☐ | |
| 3.2 | Boot with Past Alarms | TEST 2 – Boot with Past Alarms | `missed>=1` and `rescheduled>=1`, `errors=0`; past schedules detected and next occurrences scheduled | ☐ | |
| 3.3 | Boot with No Schedules (Empty DB) | TEST 3 – Boot with No Schedules | Either no recovery logs **or** explicit "No schedules found/present" or `scenario=NONE` with `rescheduled=0`, `errors=0` | ☐ | |
| 3.4 | Silent Boot Recovery (App Never Opened) | TEST 4 – Silent Boot Recovery (App Never Opened) | `rescheduled>0`, alarms present after boot, and no user launch required; `errors=0` | ☐ | |
Fill **Result** and **Notes** after running `test-phase3.sh` on your baseline emulator/device.
---
## 3. Expected Log Patterns
The script filters logs with:
```bash
adb logcat -d | grep "DNP-REACTIVATION"
```
### 3.1 Boot with Future Alarms (3.1 / TEST 1)
* Typical logs:
```text
DNP-REACTIVATION: Starting boot recovery
DNP-REACTIVATION: Loaded <N> schedules from DB
DNP-REACTIVATION: Rescheduled alarm: daily_<id> for <time>
DNP-REACTIVATION: Boot recovery complete: missed=0, rescheduled=<r>, verified=0, errors=0
```
* The script interprets this as:
* `scenario = BOOT` (via "Starting boot recovery" or "boot recovery" text or `Detected scenario: BOOT`)
* `rescheduled > 0`
* `errors = 0`
### 3.2 Boot with Past Alarms (3.2 / TEST 2)
* Typical logs:
```text
DNP-REACTIVATION: Starting boot recovery
DNP-REACTIVATION: Loaded <N> schedules from DB
DNP-REACTIVATION: Marked missed notification: daily_<id>
DNP-REACTIVATION: Rescheduled alarm: daily_<id> for <next_time>
DNP-REACTIVATION: Boot recovery complete: missed=<m>, rescheduled=<r>, verified=0, errors=0
```
* The script parses `missed` and `rescheduled` and passes when:
* `missed >= 1`
* `rescheduled >= 1`
* `errors = 0`
### 3.3 Boot with No Schedules (3.3 / TEST 3)
Two acceptable patterns:
1. **No `DNP-REACTIVATION` logs at all** → safe behavior
2. Explicit "no schedules" logs:
```text
DNP-REACTIVATION: ... No schedules found ...
```
or a neutral scenario:
```text
DNP-REACTIVATION: ... scenario=NONE ...
DNP-REACTIVATION: Boot recovery complete: missed=0, rescheduled=0, verified=0, errors=0
```
The script passes when:
* Either `logs` are empty, or
* Logs contain "No schedules found / present" with `rescheduled=0`, or
* `scenario=NONE` and `rescheduled=0`.
Any `rescheduled>0` in this state is flagged as a potential boot-recovery misfire.
### 3.4 Silent Boot Recovery (3.4 / TEST 4)
* Expected:
```text
DNP-REACTIVATION: Starting boot recovery
DNP-REACTIVATION: Loaded <N> schedules from DB
DNP-REACTIVATION: Rescheduled alarm: daily_<id> for <time>
DNP-REACTIVATION: Boot recovery complete: missed=0, rescheduled=<r>, verified=0, errors=0
```
* After reboot:
* `count_alarms` > 0
* User **did not** relaunch the app manually
Script passes if:
* `rescheduled>0`, and
* Alarm count after boot is > 0, and
* Boot recovery is detected from logs (via "Starting boot recovery"/"boot recovery" or scenario).
---
## 4. Latest Known Good Run (Template)
> Fill this in after your first clean emulator 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-phase3.sh`
* Date: 2025-11-XX
**Observed Results**
* ☐ **3.1 – Boot with Future Alarms**
* `scenario=BOOT`
* `missed=0, rescheduled=<r>, errors=0`
* ☐ **3.2 – Boot with Past Alarms**
* `missed=<m>=1`, `rescheduled=<r>≥1`, `errors=0`
* ☐ **3.3 – Boot with No Schedules**
* Either no logs, or explicit "No schedules found" with `rescheduled=0`
* ☐ **3.4 – Silent Boot Recovery**
* `rescheduled>0`, alarms present after boot, app not opened
**Conclusion:**
> Phase 3 **Boot-Time Recovery** is successfully verified on emulator using `test-phase3.sh`. This is the canonical baseline for future regression testing and refactors to `ReactivationManager` and `BootReceiver`.
---
## 5. Overall Status
> Update once the first emulator run is complete.
* **Implementation Status:** ☐ Pending / ✅ Implemented (Boot receiver + `runBootRecovery`)
* **Test Harness:** ✅ `test-phase3.sh` in `test-apps/android-test-app`
* **Emulator Verification:** ☐ Pending / ✅ Completed
Once all test cases pass:
> **Overall Status:** ✅ **VERIFIED** – Phase 3 boot-time recovery is implemented and emulator-tested, aligned with `android-implementation-directive-phase3.md` and the unified alarm directive.
---
## 6. Related Documentation
- [Phase 3 Directive](../android-implementation-directive-phase3.md) - Implementation details
- [Phase 3 Emulator Testing](./PHASE3-EMULATOR-TESTING.md) - Test procedures
- [Phase 1 Verification](./PHASE1-VERIFICATION.md) - Prerequisite verification
- [Phase 2 Verification](./PHASE2-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 3 implementation and testing pending
**Last Updated**: November 2025
Reference in New Issue View Git Blame Copy Permalink