aglinxinyuan opened a new pull request, #7631:
URL: https://github.com/apache/texera/pull/7631
### What changes were proposed in this PR?
`GmailResource` sat at **31.2% of 77 lines** in isolation. Despite the name
this is a **javax.mail/SMTP** resource, not a Google-OAuth one — no
`GoogleCredential`, no token exchange, no `clientId`, and the only credential
is an SMTP app password consumed inside an `Authenticator` callback that never
fires without a socket. Nothing worth testing here was credential-gated.
Adds 4 tests to the existing spec, taking it to **61.0%** (Codecov-style;
85.7% JaCoCo line). No socket is opened — the existing
`requireNoRealGmailSender()` guard is kept and called from every new test that
reaches `sendEmail`.
Covered: the recipient-format guard clause by clause, and the admin fan-out
driven through `MockTexeraDB`.
### Verification
9 mutations applied and reverted, production diff empty each time. The
interesting ones:
| Mutation | Result |
|---|---|
| role filter `ADMIN` → `REGULAR` | red — the REGULAR decoy row exists to
make this visible |
| `while (hasNext)` → notify only the first admin | red — which is why the
fixture holds two admins |
| `while` → `do/while` (assume at least one admin) | red on the empty-table
test |
| the TLD floor `{2,}` → `{1,}` | red |
| the null short-circuit dropped | red (NPE) |
| the regex replaced with `"^$"` (reject everything) | red — and the
six-case malformed list stayed **green**, which is exactly why its companion
test exists |
| the notification payload swapped for the raw request | **survives** — see
below |
One mutation exposed a coupling in my own fixture rather than a defect:
loosening the domain regex made the seeded `…@localhost` admin addresses
deliverable, which false-reddened the fan-out test. The fixture now uses
addresses with no `@` at all, so the fan-out is no longer coupled to the
regex's domain rules, and every mutation was re-run afterwards.
### Deliberately not included
- **The notification payload.** Replacing the whole
`userRegistrationNotification(...)` construction with the incoming request
leaves the suite green: `sendEmail` is on the companion object so nothing can
intercept what it received, and the only offline observable is which address it
rejected. The builder's contract — including its `toAdmin` branch — is
**already pinned by `EmailTemplateSpec`**, which is where it belongs, so this
is recorded rather than duplicated.
- **`getSenderEmail`.** The analyst's plan listed this as a win; I disagree
and dropped it. Both `UserSystemConfig.gmail` and `smtpPassword` default to
`""` in an unconfigured JVM, so the only available assertion cannot distinguish
this endpoint from one that leaks the SMTP password. A test there would be
vacuous.
- **Two `catch` arms in `notifyUnauthorizedUser`** are unreachable —
`sendEmail` wraps everything in a `Try` and returns a `Left`, never throwing. A
comment says so and tells the next reader to delete them rather than reach them.
- **The applicant acknowledgement, `createMimeMessage`'s tail, and the
`withDomain` `Some` arm** — the first has no observable effect offline, the
second arms `Transport.send` on the next statement, and the third needs
`Test/envVars` in `build.sbt`, which would perturb every other spec.
No production file is touched.
### Any related issues, documentation, discussions?
Closes #7630
### How was this PR tested?
```
STORAGE_ICEBERG_CATALOG_TYPE=postgres sbt "WorkflowExecutionService/testOnly
org.apache.texera.web.resource.GmailResourceSpec"
```
```
[info] Total number of tests run: 8
[info] Tests: succeeded 8, failed 0, canceled 0, ignored 0, pending 0
```
4 new on top of the existing 4. `Test/scalafmtCheck` and `Test/scalafix
--check` both pass.
### 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]
