aglinxinyuan opened a new issue, #7773: URL: https://github.com/apache/texera/issues/7773
### Task Summary Four small files across `common/workflow-core` and `common/workflow-operator`, each with a narrow untested region: | File | Coverage | Untested region | |---|---|---| | `workflow-core/.../core/executor/ExecFactory.scala` | 89.5% | the whole body of `newExecFromJavaCode` | | `workflow-operator/.../aggregate/AggregateOpExec.scala` | 87.5% | the body of `close()` | | `workflow-operator/.../source/scan/file/FileScanUtils.scala` | 90.0% | `safeToByteArray`'s non-BINARY arms, and the 7-arg `createTuplesFromFile` overload | | `workflow-operator/.../metadata/OPVersion.java` | 52.9% | most of `getVersion` | Two things make these testable that look like they should not be: 1. **`newExecFromJavaCode` can be driven for real.** A comment in `CoreExecutorReflectionSpec` (~lines 245-253) says a success-path test is impossible because system javac would only see its own classpath. That is **stale**: `common/workflow-core/build.sbt` sets `Test / fork := true`, so the forked JVM's `java.class.path` is the full test classpath and `compileCode`'s null options let javac resolve `OperatorExecutor`. A Java class implementing the trait compiles and instantiates. 2. **`OPVersion.getVersion` needs no real repository history.** Throwaway jgit repos in temp dirs can be swapped into the private static `git` field by reflection and restored in a `finally`, following `JGitVersionControlSpec`. Regions to leave alone: - `FileScanUtils` line 99 is a branch-partial only: an unreachable `Tuple2` `MatchError` leg from `Iterator.duplicate`. - `OPVersion` lines 31/36/39 are the static initializer, which runs before any test can observe it, and whose covered/missed split is decided by the checkout shape (a `git worktree` makes `.git` a file, flipping which pair is hit). - `AggregateOpExec.close()`'s `distributedAggregations = null` is an equivalent mutant: `close()` is terminal, `open()` re-nulls the field itself, so the reset is observable only via `processTuple` after `close()` with no intervening `open()` — an order the lifecycle never produces. **A hazard to plan around on Windows:** `FileScanSourceOpExecSpec`'s `afterAll` fails with `FileSystemException … test_large_binary.txt: The process cannot access the file because it is being used by another process`. That aborts the suite and takes the whole `WorkflowOperator/jacoco` task with it, so no report is emitted. It is pre-existing — `AutoClosingIterator` closes only on exhaustion, so a test that stops early leaks the handle, and POSIX `unlink` hides it on CI. Filter to your own specs rather than running the whole module. ### Task Type - [ ] Refactor / Cleanup - [ ] DevOps / Deployment / CI - [x] Testing / QA - [ ] Documentation - [ ] Performance - [ ] Other -- 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]
