Problem
The project currently lacks a real frontend testing framework for UI logic. The admin-ui and browse-ui modules ship substantial static JavaScript for the admin console, login UI, and browse UI, but the repository does not have a package.json, jsdom/Vitest/Jest setup, or Playwright configuration.
Current coverage is limited to a narrow node:test + vm contract test for admin-filter.js. That is useful, but it does not exercise DOM behavior, browser events, routing/state transitions, fetch mocking, rendered UI states, or end-to-end browser behavior. This leaves the UI easy to regress when later changes touch admin forms, browse tree rendering, login/i18n behavior, or API request logic.
Proposal
Add a frontend test setup that can lock down UI behavior at two levels:
- jsdom-level tests for deterministic DOM and component-style logic in
admin-ui and browse-ui.
- Playwright-level smoke or end-to-end tests for the real admin, browse, and login surfaces.
The tests should be wired into the normal PR validation path, either directly through CI or through the Maven lifecycle with a predictable skip flag for local development when needed.
Suggested initial coverage
- Admin UI form validation, payload construction, error handling, and success states for repositories, blob stores, users, roles, permissions, and tokens.
- Admin permission filtering in a real DOM context, including wildcard searches and empty states.
- Browse UI repository selection, search, tree expansion, package detail rendering, usage snippets, and error/empty states.
- Login modal behavior, logout behavior, and i18n text mutation logic.
- Browser smoke tests for
/admin/, /browse/, and shared login assets, including checks for major console errors.
Acceptance criteria
- A documented frontend test command exists for local development and CI.
- The repository has a real jsdom-capable test runner, such as Vitest or Jest with jsdom.
- The repository has Playwright coverage for at least the core admin, browse, and login entry points.
- CI fails when representative UI logic or smoke flows regress.
- The frontend test setup works with the current static-resource packaging used by
admin-ui and browse-ui.
Notes
This issue is about test infrastructure and regression protection. It does not require changing product behavior, but it should make future UI changes safer by turning important UI contracts into executable checks.
Problem
The project currently lacks a real frontend testing framework for UI logic. The
admin-uiandbrowse-uimodules ship substantial static JavaScript for the admin console, login UI, and browse UI, but the repository does not have apackage.json, jsdom/Vitest/Jest setup, or Playwright configuration.Current coverage is limited to a narrow
node:test+vmcontract test foradmin-filter.js. That is useful, but it does not exercise DOM behavior, browser events, routing/state transitions, fetch mocking, rendered UI states, or end-to-end browser behavior. This leaves the UI easy to regress when later changes touch admin forms, browse tree rendering, login/i18n behavior, or API request logic.Proposal
Add a frontend test setup that can lock down UI behavior at two levels:
admin-uiandbrowse-ui.The tests should be wired into the normal PR validation path, either directly through CI or through the Maven lifecycle with a predictable skip flag for local development when needed.
Suggested initial coverage
/admin/,/browse/, and shared login assets, including checks for major console errors.Acceptance criteria
admin-uiandbrowse-ui.Notes
This issue is about test infrastructure and regression protection. It does not require changing product behavior, but it should make future UI changes safer by turning important UI contracts into executable checks.