aglinxinyuan opened a new pull request, #8050:
URL: https://github.com/apache/texera/pull/8050

   ### What changes were proposed in this PR?
   
   `test_run_python_worker.py` goes from 27 tests to 42, covering the worker 
entry point's configuration-failure paths.
   
   | Metric | Before | After |
   |---|---|---|
   | Codecov fully-covered lines **today** | 32/39 | **39/39** |
   | Codecov fully-covered lines **after #8040** | 31/39 | **39/39** |
   | Branch arms | 9/12 | **12/12** |
   
   **`texera_run_python_worker.py` reaches 100% on both lines and branches.** 
+7 fully-covered lines today, +8 and +3 arms after #8040 — line 155 is a 
partial that the current branch-less report already counts covered, because it 
executes at import.
   
   The uncovered set was the argument-parsing failures (26–28), the loguru 
level configuration (35), and the missing-dependency and R_HOME paths (48, 51, 
155–156). These are what run when the worker starts with a malformed or 
incomplete configuration, so a regression there surfaces as a worker that fails 
to start with an unhelpful message.
   
   One correction to the assessment worth recording: **line 143, the R_HOME 
guard, was already at 2/2** — it was not part of the gap.
   
   ### Verification
   
   Two reviewers returned nine findings and reported **thirteen surviving 
mutants** against the first draft. All thirteen were independently reproduced 
on a pristine tree before being fixed, and all thirteen now die.
   
   **39 mutations in the final table: 38 killed, 1 equivalent, 0 real 
survivors.** The equivalent one is `frozenset` to `set` for 
`EXPECTED_CONFIG_KEYS` — reported rather than omitted.
   
   The repair also confirmed something worth stating about the measurement 
itself: `pytest`'s `importlib` import mode re-executes this module per test, 
and there is **exactly one** `<class filename="texera_run_python_worker.py">` 
entry in every report, on both sides and in the full-suite run. So the fresh 
execs attribute to the same source path rather than splitting the coverage 
entry — checked rather than assumed.
   
   Measured from `amber/` with an identical single-spec test-path scope on both 
sides, both with and without `--cov-branch` (the no-branch figure measured 
directly, not derived), per-line `hits` and `condition-coverage` read out of 
`coverage.xml` rather than from the summary percentage.
   
   Full pyamber suite: `5 failed, 1174 passed, 7 errors` against main's `1159 
passed`. Failure sets sorted and diffed — **identical by identity**, 12 
entries. `ruff check` and `ruff format --check` pass on CI's exact scope.
   
   No production file is touched; `git diff -- 'amber/src/main/*'` is empty.
   
   ### Any related issues, documentation, discussions?
   
   Closes #8046
   
   ### How was this PR tested?
   
   ```
   cd amber && python -m pytest -m "not integration" -q 
src/test/python/test_run_python_worker.py
   ```
   
   ```
   42 passed
   ```
   
   ### 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]

Reply via email to