mengw15 opened a new issue, #7879:
URL: https://github.com/apache/texera/issues/7879
### Task Summary
`ComputingUnitManagingResource` is at **51.68 % with 79 uncovered lines**,
and the largest coherent block is `createComputingUnit`'s parameter validation.
Every one of those checks runs **before** `withTransaction` and before any
Kubernetes call, so the whole section is plain unit-testable logic — each
rejection is one different field value away.
`ComputingUnitManagingResourceSpec` already provides the harness: it extends
`MockTexeraDB`, seeds users and units through the generated DAOs, instantiates
`private val resource = new ComputingUnitManagingResource`, and already asserts
`ForbiddenException` / `BadRequestException` on neighbouring endpoints. Pure
EXTEND — no Kubernetes, no new infrastructure.
### Behavior to add
**`ComputingUnitManagingResource`**
(`computing-unit-managing-service/src/main/scala/org/apache/texera/service/resource/ComputingUnitManagingResource.scala`,
codecov 51.68 % — EXTEND `ComputingUnitManagingResourceSpec`)
Build a `WorkflowComputingUnitCreationParams` per case and assert the
`ForbiddenException` and its message. The validation dispatches on `cuType`:
**`kubernetes` arm**
- `param.cpuLimit` not in `cpuLimitOptions` — *"CPU quantity '…' is not
allowed. Valid options: …"*.
- `param.memoryLimit` not in `memoryLimitOptions` — the matching memory
rejection.
- `param.gpuLimit` not in `gpuLimitOptions` — the matching GPU rejection.
- `param.shmSize` not parseable by `Quantity.parse` — the
`IllegalArgumentException` is caught and re-thrown as *"… is not a valid
Kubernetes quantity (examples: 64Mi, 2Gi)."* Pass something like
`"not-a-quantity"`.
- **shared memory above the container limit** — a valid `shmSize` whose
`Quantity` compares greater than the parsed `memoryLimit`, giving
*"Shared-memory size (…) cannot exceed the total memory limit (…)"*.
- **JVM heap above total memory** — `jvmGB > memGB`. Note `memGB` has three
arms that all need covering: a `memoryLimit` ending in `Gi` (parsed directly),
one ending in `Mi` (divided by 1024), and one with neither suffix (parsed
directly). Use a `Mi` value large enough that the division matters, so the
middle arm is not silently equivalent to the others.
- The accepted path: a params object where every check passes, so each guard
is exercised on both sides rather than only when it throws.
**`local` arm**
- `param.uri.forall(_.trim.isEmpty)` — assert *"URI is required for local
computing units"* for both an absent URI and one that is only whitespace, and
that a real URI is accepted.
**Unsupported type**
- The trailing `case _` — *"Unsupported computing-unit type: …"*.
**`getComputingUnitResourceLimit`** (line 205)
- The `WorkflowComputingUnitTypeEnum.local` arm returns
`WorkflowComputingUnitResourceLimit("NaN", "NaN", "NaN")` with no Kubernetes
involvement — assert that directly. The `kubernetes` arm calls
`KubernetesClient.getPodLimits` and is out of scope here.
Also uncovered and worth picking up while in the file: `renameComputingUnit`
(line 647) and the access branch at line 584.
Determinism notes:
- Read the allowed-options lists from the same config the resource reads
(`KubernetesConfig`) rather than hardcoding values a config change would
invalidate.
- Assert on the exception type and a distinctive fragment of the message,
not the entire string.
- Seed any user/unit rows the test needs inside the test.
Out of scope: anything calling `KubernetesClient`, and
`computingUnitEnvironmentVariables`, whose `EnvironmentalVariable.get(...).get`
calls make it depend on the process environment.
Verify locally before opening the PR: `sbt
ComputingUnitManagingService/testOnly *ComputingUnitManagingResourceSpec`, plus
`scalafmtCheck` and `scalafix --check`.
### 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]
