aglinxinyuan opened a new pull request, #7958:
URL: https://github.com/apache/texera/pull/7958
### What changes were proposed in this PR?
Two files in the AsterixDB source family. 52 tests → 68
(`AsterixDBSourceOpDescSpec` 5 → 18, `AsterixDBSourceOpExecSpec` 47 → 50),
counts read from the JUnit XML rather than estimated.
| File | Codecov | JaCoCo line-hit | Branch arms |
|---|---|---|---|
| `AsterixDBSourceOpDesc.scala` | 42/50 = 84.0% → **49/50 = 98.0%** | 100% →
100% | 12 missed → **1** |
| `AsterixDBSourceOpExec.scala` | 91/104 = 87.5% → **92/104 = 88.5%** | 99%
→ 99% | 19 missed → **15** |
**+8 fully-covered lines and 15 branch arms closed.** Note the line-hit
metric does not move at all: every gain is a branch arm flipping a Codecov
"partial" into a "hit". That is the case Codecov penalises and line-hit hides,
and it is the whole content of this PR.
The `OpExec` half was assessed earlier at about 1 line, and that held — it
contributes +1. The `OpDesc` half carries the bundle.
### Verification
30 mutations, **29 killed, 1 survivor.**
The first draft claimed no survivors; **five real, semantic, non-equivalent
mutants survived it**, all five re-run and confirmed before anything was
changed. Its counts were also stale (`testsAfter: 64` against an actual 68) and
two mutation rows undercounted their failures.
Three repairs are worth naming:
- **The stub answered every statement identically**, which made the query
assertions vacuous — an exchanged query passed. It now records the decoded
statements and asserts on them.
- **A mapping assertion was deleted rather than kept**:
`asterixDBVersionMapping.get(host) shouldBe Some("0.9.9")` asserted the test's
own fixture, not production.
- Two new `OpDesc` tests pin ordering that nothing constrained: that
`updatePort` is applied by `sourceSchema` *before* it issues any query, and
that the unset-field error names host, port, database in that order.
**The survivor, and it is a real gap rather than an equivalent mutant:**
adding `cachedTuple = None` to `AsterixDBSourceOpExec.close()` survives all 100
tests. Today, after `hasNext` then `close()`, a fresh `produceTuple()` still
hands out the previously peeked row; under the mutant it does not. `close()`
clears the iterator and the query string but not the cached tuple. **Neither
side is pinned deliberately** — the behaviour looks unintended, and asserting
either way would cement a decision nobody has made.
### Deliberately not included, with bytecode evidence
- **`AsterixDBSourceOpExec:331` can never be fully covered.** `javap` shows
offset 225 pushing `iconst_1` unconditionally for the `| _` alternate, so the
`ifeq` has a permanently dead side. It went from 4 missed arms to 1 and still
reads as partial, moving Codecov by exactly zero.
- **Lines 227 and 239** are the null-comparison arms of scalac's `==`
expansion on `attr.getType`; reaching them needs an `Attribute` carrying a null
`AttributeType`.
- **Line 152's `if (values == null) return null` is dead**: `javap` confirms
`CSVParser.parse` returns a `scala.Option`, so `values` is never a Java null.
- **Line 268** re-checks a condition its only caller already guards, so the
false arm cannot occur.
- `AsterixDBSourceOpDesc` line 177 keeps one arm (mb=1/cb=3) for the same
structural reason.
No production file is touched, and no stray `test_large_binary.txt` was left
behind.
### Any related issues, documentation, discussions?
Closes #7956
### How was this PR tested?
```
sbt "WorkflowOperator/testOnly
org.apache.texera.amber.operator.source.sql.asterixdb.AsterixDBSourceOpDescSpec
org.apache.texera.amber.operator.source.sql.asterixdb.AsterixDBSourceOpExecSpec"
```
```
[info] Total number of tests run: 68
[info] Tests: succeeded 68, failed 0, canceled 0, ignored 0, pending 0
```
The whole `asterixdb` package is green at 100 tests. `Test/scalafmtCheck`
passes.
### 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]
