Files
2026-09-09 15:19:03 +02:00

2.8 KiB
Raw Permalink Blame History

Executable reminder acceptance scenarios

PushCucumberTest executes the service scenarios in the canonical gherkin/push-tests.feature, including all five WJ-029 exclusion examples. WJ-033, opening a notification in the browser, remains outside this suite. WJ-060 adds regression coverage for removing a previously set day-off marker.

Every scenario uses an isolated, freshly migrated H2 file and production device login, subscription, eligibility, queue, dispatcher and scheduler code. A fixed clock makes the local 20:0022:00 window deterministic. The maintenance flag is a real temporary file. The transport records messages and returns accepted; it never connects to a push provider. Registration uses a valid generated P-256 public key. No real email or push messages are sent.

Assertions cover delivery to the opted-in phone only, all five exclusion reasons, actual work and day-off service writes, maintenance catch-up, the persistent daily delivery ledger, expiration of an abandoned queue claim, both weekend dates, Berlin-to-Tokyo timezone reporting and suppression after work written by another authenticated device of the same owner. They inspect destination, dated URL, daily tag, TTL and stored delivery status. The timezone case verifies no delivery immediately before Tokyo 20:00 and delivery at that boundary after the reported change.

These are service-level acceptance tests, not browser permission, encryption transport, Android installation or real background-delivery acceptance. Those checks remain separate.

Run with:

JAVA_HOME=/path/to/jdk25 ./gradlew --no-daemon test --tests '*PushCucumberTest' -Pproduction=true

The normal tools/ci-jvm run includes the suite. Its Cucumber JSON report is build/reports/cucumber/push-service.json.

The added WJ-060 scenario first failed against the existing eligibility query: it treated any stored day-off row as a blocker, even after DayOffService changed marked to false. Eligibility now requires marked = true; this is a query correction without a schema change.

The first run also reproduced the prior CI failure in the habit component fixture. UI.setCurrent uses a weak reference; the fixture now retains its UI strongly for the whole scenario. The push fixture opens its long-lived anchor connection after migration and database reopening, avoiding H2 retaining a constraint comparator tied to the closed migration session. These fixture corrections do not alter production connection handling.

Validation for 0.1.29-SNAPSHOT: the corrected focused run and full local CI both passed. The full JVM report contains 172 cases, 162 executed with zero failures/errors and ten skipped browser/harness cases. All 12 push, six habit and 13 work examples passed; all 68 operations tests, 17 frontend tests, production startup and admin recovery checks passed.