You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@texera.apache.org by "aglinxinyuan (via GitHub)" <gi...@apache.org> on 2026/08/26 08:49:52 UTC

[I] Cover the result, export and runtime-statistics services [texera]

aglinxinyuan opened a new issue, #7991:
URL: https://github.com/apache/texera/issues/7991

   ### Task Summary
   
   Four frontend services and one component, each about 3 lines of gap:
   
   | File | Coverage |
   |---|---|
   | `workspace/service/code-editor/ui-udf-parameters-sync.service.ts` | 94.5% |
   | `workspace/service/workflow-result/workflow-result.service.ts` | 97.5% |
   | `.../workflow-result-export/workflow-result-export.service.ts` | 96.8% |
   | `.../workflow-runtime-statistics.component.ts` | 92.8% |
   
   **Two files that look like candidates are not.** `workflow-action.service.ts` shows 3 partials and is provably unwinnable — all three compare a `Y.Map` value against a freshly-constructed `{x, y}` by reference, so the guard cannot fire in production and the only test-only route is a test of the mock. And `user-dataset-file-renderer.component.ts` contributes **zero**: two dead `??`/`||` fallbacks already gated by `isPreviewSupported`, plus an unreachable partial.
   
   That third one comes with a defect worth filing separately and **not** pinning: the empty-row filter in `loadTabularFile` is entirely dead code. `for (const cell in row)` enumerates array *index strings* (`"0"`, `"1"`, …), never `""`, so the `cell != ""` test is always true, `areCellAllEmpty` is always false, and no row is ever filtered — verified directly in node. Fixing it means iterating values with `for...of`, which is a production change.
   
   Traps:
   
   1. **Do not add a `vi.mock` for Plotly in the runtime-statistics spec.** Per #6580 it is green solo and red on CI, because `@angular/build`'s unit-test runner hard-codes `isolate: false` so all specs share one module registry. The existing spec already uses a mock-free real-Plotly pattern; stay inside it.
   2. **The same shared registry rules out mutating an exported const at test time.** Reaching two of `user-dataset-file-renderer`'s lines would need `MIME_TYPE_SIZE_LIMITS_MB` mutated, which would leak into every other spec importing that module.
   3. `workflow-result.service.ts:222` is an exhaustive-union arm — an equivalent mutant, not a gap.
   4. `workflow-runtime-statistics.component.ts:137` is the weakest of the winnable lines: the template renders exactly 8 tabs for 8 metric keys, so an out-of-range index is unreachable through the real UI. It is a defensive default on a *public* method reachable with a legal argument, so it counts — but say so.
   5. `frontend/junit.xml` and `coverage/` are regenerated every run; `junit.xml` is not gitignored and fails the licence-header check if committed. Expect a large volume of benign jsdom `getContext not implemented` noise from Monaco.
   
   ### 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: notifications-unsubscribe@texera.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [I] Cover the result, export and runtime-statistics services [texera]

Posted by "aglinxinyuan (via GitHub)" <gi...@apache.org>.
aglinxinyuan closed issue #7991: Cover the result, export and runtime-statistics services
URL: https://github.com/apache/texera/issues/7991


-- 
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: notifications-unsubscribe@texera.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org