2.4 KiB
Executable habit acceptance scenarios
HabitCucumberTest executes the six @service scenarios in the canonical gherkin/habit-tests.feature: WJ-002, WJ-003, WJ-004, WJ-009, WJ-056 and WJ-057. The default names in WJ-057 now match the agreed English names, Reading and Walks. Browser-tagged scenarios remain pending.
Each scenario gets a freshly migrated H2 file, an authorized Alice owner fixture, production services, and a fixed Wednesday clock. No HTTP login or actual mail delivery is simulated by these fixtures. Files and the current Flow UI are cleaned up after each scenario.
The tests verify negative-count rejection, stale-version conflict, Monday–Sunday allowance history, first allowance without retroactive changes, advisory daily/weekly bounds, and one-time editable defaults. WJ-003 constructs two real HabitCounter components from the same version and clicks their buttons. The second component must display the conflict and refreshed stored count without retrying the mutation. The conflict handler now re-renders the current counter with its alert; it previously left the old count visible.
WJ-056 checks the actual Flow status elements and counter warning class for both maximum and minimum violations, rather than recreating the presentation logic inside the test. These are server-side component checks; they do not prove browser rendering, responsive layout or cross-device transport.
Run the suite with:
JAVA_HOME=/path/to/jdk25 ./gradlew --no-daemon test --tests '*HabitCucumberTest' -Pproduction=true
The normal tools/ci-jvm run includes the suite. Its Cucumber report is build/reports/cucumber/habit-service.json. Missing selected steps fail the run; browser scenarios are not selected or reported as passed.
Validation for 0.1.27-SNAPSHOT: all six habit scenarios and all 13 work scenarios passed in the full local CI run. The JVM report contains 159 cases, 150 executed with zero failures/errors and nine skipped (browser coverage remains open). All 68 operations tests, 17 frontend tests, production JAR startup and admin recovery checks passed. No database migration or real message delivery was performed.
CI follow-up: the first remote run exposed a fixture lifetime issue: Vaadin's current UI is weakly referenced and could be collected between steps. The fixture now keeps a strong scenario-owned UI reference. The production conflict behavior is unchanged by that correction.