aglinxinyuan opened a new issue, #7918: URL: https://github.com/apache/texera/issues/7918
### Task Summary Two small gaps where the behaviour runs today but is asserted nowhere: | File | Coverage | |---|---| | `frontend/src/app/common/util/email.ts` | 62.5% — 1 missed + 2 partial of 8 lines, and **no spec at all** | | `common/auth/.../auth/UnauthorizedException.scala` | 66.7% — 3 missed of 9 lines | `email.ts` is the only un-spec'd file in its `util` directory, and it sits on the sign-in path: `AuthService` reads `email` out of the email-request modal's `getValues()`. Its coverage comes entirely from indirect drivers (`auth.service.spec.ts`, and `texera-login.component.spec.ts` through a static call), so the regex itself is unconstrained — it can be replaced with `/@/`, have its trailing anchor dropped, or be narrowed to `\.com$`, and nothing in the repository fails. `UnauthorizedException`'s case is different and worth knowing as a general pattern: **its spec exists but is in the wrong module.** `UnauthorizedExceptionMapperSpec` lives in `access-control-service` while the class it tests lives in `common/auth`, and since JaCoCo reports per module, the spec credits that file with nothing. Relocating it to `common/auth/src/test` is a test-only change that takes the file to 100% — but be clear in the PR that this is re-attribution of already-running behaviour rather than new testing. Worth knowing before starting: 1. **One of `email.ts`'s three gap lines is promoted only by an unreachable null-guard arm**, so the honest frontend yield is +2 lines and +1 arm, not +3 and +2. Do not claim the larger figure. 2. **`enableSuppression = false` on `UnauthorizedException` cannot be pinned.** Flipping it leaves the whole module green; it is observable in principle via `getSuppressed`, but nothing in the repository calls it. Record it as a survivor rather than inventing an assertion. 3. **`LargeBinaryManager` looks like a third candidate and is worth zero.** Reaching it requires a `build.sbt` change with LICENSE-binary fallout. 4. Re-compile `access-control-service` after moving the spec, to confirm nothing there depended on it. 5. A new frontend spec needs the Apache licence header, and `frontend/junit.xml` and `frontend/coverage/` are regenerated by every run and must not be committed. ### 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]
