aglinxinyuan opened a new pull request, #7835: URL: https://github.com/apache/texera/pull/7835
### What changes were proposed in this PR? Test-only. **No production file changes.** `AuthResource`, measured with `WorkflowExecutionService/jacoco` under an identical filter for the before and after runs: | Metric | Before | After | |---|---|---| | Codecov metric (fully-covered lines) | 85.1% — 80/94, 4 missed + 10 partial | **90.4% — 85/94, 0 missed + 9 partial** | | JaCoCo line-hit | 95.7% (90/94) | **100% (94/94)** | | Branches | 55.0% (44/80) | **62.5% (50/80)** — 6 arms closed | Tests **36 → 43**. Zero missed lines remain. Covered: the whole `logger.warn` + early-return block in `createAdminUser` (lines 137-141), both blank-credential legs of its guard, the already-an-email branch, the placeholder-email adoption guard, and the registration password validation. A useful confirmation for anyone measuring this module: the filtered baseline reproduced the reported percentages **exactly**, which pins down that the metric Codecov shows is fully-covered-lines / total-lines — partials count against you. That is why the JaCoCo line-hit figure (100%) and the Codecov figure (90.4%) differ so much here. ### 5 mutations, 5 killed, no survivors Each applied alone, reverted with the production diff verified empty, and the failing test named: | Mutation | Killed by | |---|---| | drop the admin-username leg of the guard at :132 | `createAdminUser should create nothing…` | | drop the admin-password leg of the same guard | same test | | warn about the address clash at :141 but bootstrap anyway | `createAdminUser should not create an…` | | drop the credential leg of the adoption guard at :222 | `setEmail should not adopt a placeholder…` | | drop the null leg of the registration password guard at :274 | `register should reject a missing pass…` | ### The companion target was dropped, at an honest zero `FinalizeCheckpointHandler` was bundled into this work at an assessed 5 closable lines. **The real count is 0**, and it was proved rather than guessed: a throwaway probe spec ran the exact production sequence and got ``` java.io.NotSerializableException: No configured serialization-bindings for class [org.apache.texera.amber.engine.common.CheckpointState] ``` from `Serialization.serializerFor` inside `SequentialRecordWriter.writeRecord`. `CheckpointState` extends nothing, `cluster.conf` binds only `java.io.Serializable` → kryo with `allow-java-serialization = off`, and `AmberRuntime.serde` is a JVM-global with no setter. Every available seam is a production one. Notably the #7770 harness was **not** the blocker: `FinalizeCheckpointHandlerSpec` already drives a real `WorkflowWorker` through `TestActorRef` and already reaches lines 66-68 — the wall is one line further in. Adding `amber/src/test/resources/application.conf` would merge a test-only binding in, but it would change the Pekko config of every spec in the shared JVM *and* make a green test out of a path production cannot execute. Rejected on both counts. So this PR is one file rather than two, and smaller than the bundle it was scoped as. I would rather say that than pad it. ### Also deliberately not covered `AuthResource.scala:49` (`case class SetEmailRequest`) carries 20 missed branch arms — the largest single chunk left — but they are compiler-synthesized `equals`/`hashCode`/`copy`/`toString`/`canEqual`/`product*` members. A Jackson round-trip test would pin the wire field name `email` and incidentally clip a few `equals` arms; that is padding, not pinning, so it is left out. ### Any related issues, documentation, discussions? Closes #7834 ### How was this PR tested? ``` STORAGE_ICEBERG_CATALOG_TYPE=postgres sbt "WorkflowExecutionService/testOnly org.apache.texera.web.resource.auth.AuthResourceSpec" ``` ``` [info] Tests: succeeded 43, failed 0, canceled 0, ignored 0, pending 0 ``` `Test/scalafmtCheck` passes; `git diff -- '*/src/main/*'` is empty. ### Was this PR authored or co-authored using generative AI tooling? Generated-by: Claude Code (Opus 5) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
