3.2 KiB
Executable work acceptance scenarios
WorkCucumberTest runs all @service scenarios from the canonical gherkin/work-tests.feature through Cucumber's JUnit Platform engine. The feature text and stable WJ tags are unchanged. Gradle copies the canonical feature files into test resources; there is no separately maintained test copy.
The selected set comprises WJ-043, WJ-044 (four examples), WJ-045, WJ-046, WJ-047, WJ-049, WJ-050, WJ-052, WJ-053 and WJ-055: 13 executed cases. The three @browser scenarios in that file remain separate pending browser bindings. Other feature files are not claimed as executed by this suite; the table in acceptance.md distinguishes their status.
Each scenario uses a new temporary H2 file migrated with the production Liquibase changelog, a fixed clock, an authorized Alice owner fixture and the real CatalogService, WorkService and owner transaction implementation. The fixture does not simulate HTTP login. The database connection and files are closed/deleted after each scenario. Concurrent additions use separate worker transactions and a barrier, with bounded result waits.
Invalid fractional durations and missing customer/project fields go through WorkDraftParser, the same production parser called by the Flow form. This parser was extracted without changing its validation or payload mapping. Tests do not invent a permissive or stricter test-only conversion from text to WorkInput. The date-move scenario also parses the actual edited-form payload before invoking the service.
Assertions check stored entries, per-day and monthly customer totals, project ownership, historical names, active selection lists, unchanged dates while travelling, exact rejection reasons and preservation of existing data after rejected edits. Exceptions outside the expected domain/input categories fail the scenario rather than being counted as rejection.
Run just this suite with the pinned JDK:
JAVA_HOME=/path/to/jdk25 ./gradlew --no-daemon test --tests '*WorkCucumberTest' -Pproduction=true
The normal tools/ci-jvm test task includes it automatically. Reports are written to build/reports/cucumber/work-service.json and the normal Gradle test report. Cucumber report publication is disabled. The root-engine discovery workaround prevents duplicate execution; the explicit suite selects its feature and tag filter. Missing step definitions in the selected suite fail execution, and JUnit's suite fails if no tests are discovered.
Integration follows the official Cucumber JUnit Platform documentation, using the previously pinned Cucumber BOM version 7.34.8. Dependencies remain test-only.
Targeted validation: all 13 cases passed, with every reported step marked passed. This is an automated service/form-boundary acceptance result, not a claim of browser interaction or completed overall acceptance.
Full local CI also passed for 0.1.25-SNAPSHOT: 148 reported JVM cases (144 executed, four skipped), zero failures/errors; 68 operations tests; 17 frontend tests; production JAR startup and admin recovery smoke checks. The Cucumber JSON report contains exactly 13 scenarios with all steps passed. No production database or real mail delivery was involved.