aglinxinyuan opened a new pull request, #8132: URL: https://github.com/apache/texera/pull/8132
### What changes were proposed in this PR? Three existing specs extended and one new, 66 tests to 73. | File | Codecov-missed | Newly covered | |---|---|---| | `StableMergeSortOpExec.scala` | 5 → **1** | 62, 71, 269, 275 | | `FilterPredicate.java` | 4 → **2** | 66, 80 | | `SklearnClassifierOpDesc.scala` | 2 → **0** | 28, 30 | | `TaskCodegen.scala` | 2 → **1** | 80 | **+9 fully-covered lines and +4 branch arms** — 279/307 → 288/307 across the bundle (90.9% → 93.8%). ### Two files from the original scope were dropped - **`AsterixDBSourceOpExec`** (12 missed of 104) — the nominated headline. No spec written; it stays 12 → 12. - **`OPVersion.java`** (3 missed of 18) — stays 3 → 3. Both are named rather than quietly omitted, since the bundle was pitched partly on `AsterixDBSourceOpExec`'s 11 partial arms. A known defect in `AsterixDBSourceOpExec` is deliberately **not** pinned: `close()` does not clear the cached tuple. ### Verification **16 mutations, all 16 killed** — the builder's 9 re-derived from scratch, plus 7 that two reviewers found surviving the first draft. Each was preceded by a false-kill guard (sha256 of all four production files against a scratch snapshot **and** an empty `git diff -- '*/src/main/*'`) and followed by a revert-from-snapshot that re-verified both; all 16 revert checks logged clean. Anchor text was asserted to occur exactly once before each apply. No mutation failed to compile, so none was discarded. Two reviewers returned nine findings; all repaired. The repair added discrimination, not count — the coverage figures are byte-identical to the builder's and were reproduced independently rather than adopted. Measured with two `WorkflowOperator/jacoco` runs, one fresh sbt JVM each, the jacoco directory removed between them, `AMBER_TEST_FILTER=skip-integration TEXERA_SERVICE_LOG_LEVEL=WARN` to match CI. Both sides used an identical suite-name filter in a throwaway `.sbt` that excluded `FileScanSourceOpExecSpec` — that suite aborts on Windows in its own cleanup, and because sbt-jacoco runs unforked and skips `saveRuntimeData` when the test task fails, an unfiltered run emits an **all-zero** report rather than a partial one. The throwaway file was deleted. The before-state restored each modified spec with `git show HEAD:<exact single path>` and deleted the new one — never `git checkout -- <directory>`. **A pre-existing flake found while reconciling the module totals, and reported rather than absorbed.** Module-wide branch misses moved 1150 → 1147, which is −3 where these four files contribute −4. Diffing every sourcefile between the two reports isolated the discrepancy to `IntervalJoinOpExec.scala` (21 → 22 missed arms), a file this PR never touches. Its covering spec uses an unseeded RNG, so its per-run branch totals are not stable — worth knowing before anyone quotes module-wide arm counts from a single run. No production file is touched; `git status --porcelain` is clean, with no leaked `test_large_binary.txt` and no throwaway probe spec left behind. ### Any related issues, documentation, discussions? Closes #8130 ### How was this PR tested? ``` sbt "WorkflowOperator/testOnly org.apache.texera.amber.operator.sort.StableMergeSortOpExecSpec org.apache.texera.amber.operator.filter.FilterPredicateSpec org.apache.texera.amber.operator.sklearn.SklearnClassifierOpDescCodegenSpec org.apache.texera.amber.operator.huggingFace.codegen.TaskCodegenSpec" ``` ``` [info] Total number of tests run: 73 [info] Tests: succeeded 73, failed 0, canceled 0, ignored 0, pending 0 [info] All tests passed. ``` `WorkflowOperator/Test/scalafmtCheck` and `WorkflowOperator/Test/scalafix --check` both pass. Re-run after rebasing onto current `main`. ### 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]
