Summary
Currently, when a test run is stopped and then restarted, all tests run again from the beginning with the UI fully reset. It would be useful to allow resuming from the point where the test run was interrupted.
Details
The test runner progresses through several states:
ExecutingValidations (source data checks)
ValidatingCalendarData (calendar data for all years)
SpecificUnitTests (per-event accuracy tests)
To support resuming, we would need to:
- Preserve all index counters (
index, calendarIndex, yearIndex, messageCounter) and the current TestState when stopping
- Preserve success/fail counters and their UI state
- On resume, restore the saved state and continue sending messages from where the run was interrupted
- Distinguish between "Resume" and "Restart" in the UI (e.g., two separate buttons, or a long-press vs short-press)
Context
This was considered during the implementation of the stop button feature, but the restart-from-scratch approach was chosen for simplicity. See the stop button implementation for the current reset logic.
🤖 Generated with Claude Code
Summary
Currently, when a test run is stopped and then restarted, all tests run again from the beginning with the UI fully reset. It would be useful to allow resuming from the point where the test run was interrupted.
Details
The test runner progresses through several states:
ExecutingValidations(source data checks)ValidatingCalendarData(calendar data for all years)SpecificUnitTests(per-event accuracy tests)To support resuming, we would need to:
index,calendarIndex,yearIndex,messageCounter) and the currentTestStatewhen stoppingContext
This was considered during the implementation of the stop button feature, but the restart-from-scratch approach was chosen for simplicity. See the stop button implementation for the current reset logic.
🤖 Generated with Claude Code