mengw15 opened a new pull request, #7915: URL: https://github.com/apache/texera/pull/7915
### What changes were proposed in this PR? Extends `menu.component.spec.ts` over the class-file gaps the issue lists — the run-button descriptor switch, the `ngOnInit` subscriptions, the report failure paths, and the metadata/persist handlers — with 22 tests. This takes `menu.component.ts` to full coverage. Measured locally with `--coverage`: | `menu.component.ts` | Before | After | | --- | --- | --- | | lines | 248/274 (90.51 %) | **274/274 (100 %)** | | statements | 253/281 | **281/281** | | branches | 55/74 (74.32 %) | **74/74 (100 %)** | | functions | 65/86 | **86/86** | **`getRunButtonBehavior`** — the existing tests assert the descriptors but never invoke them, so every `onClick` was an uncalled function. The new tests call the returned handler and assert its effect: `Connect` and `Run` both reach `runWorkflow`; the invalid, empty and connecting descriptors are inert; the four transient states (`Initializing`, `Pausing`, `Resuming`, `Recovering`) each return a disabled `loading` descriptor whose click does nothing; and the `default` arm falls back to `Run`. That last case is only reachable with a value from outside `ExecutionState` — every member has its own case — so the test casts one in and says so in a comment. **`ngOnInit`** — an execution-state event now drives the subscription that sets `executionState` and re-applies the button (`Running` → `Pause`, `Paused` → `Resume`), through a stubbed state stream on a second fixture. The export-button flag is exercised on both sides of its `||`: with the feature off it stays deactivated whatever the results say, and with it on the result flag decides. **`onClickGenerateReport`** — the success path now runs with two operators and a backend that returns only one result, which covers both sides of the `find(...)?.html || ""` ordering and the operator-id `map`. Both failure paths are covered too: a retrieval error reports `"Error in retrieving operator results: …"` and closes the blocking notification, and a snapshot error reports its own message without ever asking for results. **`onClickEditDescription`** — a workflow with no description seeds the editor with `""`; an edit stores the updated metadata, persists it while logged in and closes the modal; logged out it closes without persisting. **`persistWorkflow`** — with a project id and a saved `wid` the workflow is filed under the project; with no `wid` the project is left alone; a failed save is reported and clears `isSaving`. `onWorkflowNameChange` gets the same login guard on both sides. **Metadata display** — the debounced refresh subscription is driven by `setWorkflowMetadata`: a persisted workflow gets a `Saved at …` stamp and the deferred width fix-up runs, an unsaved one leaves the stamp empty, and the version-display handler stamps `particularVersionDate` when the metadata carries a creation time. No production code was changed. ### Any related issues, documentation, discussions? Closes #7912. ### How was this PR tested? `ng test --watch=false --include src/app/workspace/component/menu/menu.component.spec.ts` — 98 passed (76 before, 22 new), repeated 3× for stability; the whole `workspace/component/menu/**` folder stays green (104). `yarn format:ci` clean. Failure path verified by breaking one assertion in each of the 22 new tests: 22 failed / 76 passed, non-zero exit, and no pre-existing test was disturbed; then restored to green. Determinism: every stream is stubbed with `of(...)` / `throwError(...)` or a `Subject` the test pushes, so nothing waits on a backend. The two metadata tests install fake timers only for the 100 ms `debounceTime` the subscription itself uses, and `afterEach` restores real timers; the deferred `setTimeout(adjustWorkflowNameWidth, 0)` is spied rather than measured, since jsdom reports every element as zero-width. Dates are asserted by shape, not by rendered value, so the runner's time zone cannot change the outcome. Extra fixtures are destroyed in a `finally`, and `vi.restoreAllMocks()` runs in each new block's `afterEach`. ### Was this PR authored or co-authored using generative AI tooling? Generated-by: Claude Code (Opus 4.8 [1M context]) -- 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]
