lxbme opened a new pull request, #3447:
URL: https://github.com/apache/apisix-dashboard/pull/3447
Please answer these questions before submitting a pull request, **or your PR
will get closed**.
**Why submit this pull request?**
- [x] Bugfix
**What changes will this PR take into?**
This closes three of the "Test-suite gaps" items of the frontend review in
#3417, in one PR (all are test additions/fixes plus one small locale key fix).
**1. i18n key-parity unit test (`src/locales/locale-parity.test.ts`)**
There was no test that every locale defines the same keys as the base
(`en`); a missing key falls back to English silently at runtime, so a locale
can drift out of parity unnoticed. This adds a unit test that flattens each
`src/locales/*/common.json` and asserts its key set exactly matches `en` (no
missing, no extra). It checks key structure only, not whether values are
translated (a locale may legitimately share a string with English).
Writing it surfaced a real drift: the `a11y.openSettings` /
`a11y.selectLanguage` / `a11y.toggleNavigation` keys existed in `en`/`zh` but
were entirely absent from `de`/`es`/`tr`. Those three keys are added to the
missing locales. **Their values are the English strings as placeholders** —
this matches the current runtime behaviour (the missing keys already fell back
to English) and does not fabricate translations; they are flagged for a
native-speaker pass. The test now enforces that no future key can be added to
`en` without being added everywhere.
**2. Sensitive-field masking assertion
(`e2e/tests/regression/secrets.sensitive-field-masked.spec.ts`)**
Masking was only ever asserted for the admin key inside the Settings modal.
Sensitive fields outside it — the secret manager's token / access keys /
private key, all rendered through the same `PasswordInput` — had no test. This
pins the Vault-secret Token field on the Add Secret page as masked
(`type=password`), the regression that would surface if it were swapped to a
plain `TextInput`.
**3. `zOneOf` / service upstream selection quadrants
(`e2e/tests/regression/services.upstream-or-id-selection.spec.ts`, renamed from
`validation.zOneOf-single-field.spec.ts`)**
The old spec tested only the inline-upstream-only case — one an inverted
implementation would also pass. Investigating it turned up two facts worth
recording:
- The `zOneOf` validator is **not applied by any form** in the app; the
Service form resolves the inline-`upstream` vs `upstream_id` choice leniently
in the submit pipeline (`produceRmUpstreamWhenHas('upstream_id')` drops the
inline upstream when an id is given).
- The `zOneOf` validator itself is already covered across all four quadrants
by `src/utils/zod.test.ts`.
So the missing coverage was integration-level, on the Service form's real
behaviour. The spec is rewritten (and renamed for accuracy) to pin all four
quadrants: inline-only → stored inline; id-only → stored as reference; both →
id wins and the inline upstream is dropped; neither → the service still saves.
Its header comment records the two facts above.
**Related issues**
Part of #3417
**Checklist:**
- [x] Did you explain what problem does this PR solve? Or what new features
have been added?
- [x] Have you added corresponding test cases?
- [x] Have you modified the corresponding document?
- [x] Is this PR backward compatible? If it is not backward compatible,
please discuss on the mailing list first
Not in this PR (separate, larger test-suite items): the general
create→read→noop-edit-save→deep-diff round-trip invariant; cross-browser /
pinned-image CI; and the `waitForTimeout` removal + parallel-safety refactor.
Mutation-failure feedback (the remaining test-gap item) is already covered by
existing specs (`network-error.mutation-toast`, `form.mutation-failure-error`)
across create/update/delete/network-level.
Verified with `tsc`, ESLint, the unit suite, and the full e2e suite. The
parity test's sensitivity was confirmed by temporarily removing a key from one
locale (goes red naming the exact missing key) and restoring it.
--
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]
