dengliming opened a new issue, #657: URL: https://github.com/apache/shenyu-dashboard/issues/657
## Problem The dashboard needs automated regression protection for configuration editing, namespace switching, authorization, and failure handling. A successful lint/build does not verify these behaviors. Inspection of the current `master` tree found: - Five `*.test.js` files with 32 `it(...)` declarations, covering path utilities, permission checks, menu matching, breadcrumbs, and a simple result-page render. - Existing `test`, `test:component`, and `test:all` scripts, with Roadhog and Enzyme in the current toolchain. - `tests/run-tests.js` starts the development server and invokes `npm test`, but the current tree contains no business browser-test suite. - `.github/workflows/build.yml` runs lint and build without running tests. These are static inspection findings; this proposal does not claim that the existing tests currently pass or provide a measured coverage percentage. Related: #652 reports stale Ant Design Pro E2E tests and a failing `test:all` command against an earlier revision. Its referenced `src/e2e` files are absent from the current tree. Phase 1 should reconcile that report with the current implementation; this issue tracks the broader testing strategy and follow-up work. ## Proposed approach Build three complementary layers: 1. **Unit tests:** configuration conversion, request construction, permission decisions, and state transitions. 2. **Component/page interaction tests:** validation, edit initialization, authorization-dependent UI, and error handling, using controlled API responses. 3. **Browser E2E tests:** a small set of critical workflows against a disposable ShenYu Admin environment, including persistence checks through the API or a fresh page load. Use the existing build stack initially. Proposed tooling is a working Jest-compatible unit-test setup, React Testing Library at a version compatible with React 16 for new interaction tests, and Playwright for new browser tests. Confirm compatibility during phase 1. A React/Vite migration should not be a prerequisite for adding regression protection. ## Work breakdown Each item below is intended to be independently deliverable as one PR or a small follow-up issue. Phase 1 establishes the baseline; phases 2 and 3 can then proceed independently. Phase 4 adds real-backend integration coverage. Add each CI gate alongside its corresponding suite. ### 1. Restore a reliable test baseline and unit-test CI — P0 - [ ] Audit all existing test commands and reproduce or reconcile #652 against current `master`. - [ ] Make the useful existing tests pass; repair or remove obsolete scaffolding with an explanation. - [ ] Provide explicit, non-interactive commands for unit tests and coverage reporting. - [ ] Add the unit-test command to pull-request CI. - [ ] Document the supported Node version and clean-install/test commands. **Acceptance:** a clean checkout can run the documented unit command without a backend or browser; a failing assertion makes the CI job fail; obsolete E2E commands are repaired or replaced with a clearly documented migration path. ### 2. Protect core business logic — P1 - [ ] Test request serialization, token propagation, and request parameters, including namespace IDs. - [ ] Cover HTTP 401, application-level `code: 401`, network failures, and error propagation to callers. - [ ] Test permission decisions and namespace-dependent state updates. - [ ] Test configuration/form conversion, including empty values, booleans, numbers, nested JSON, and preservation of fields that are not edited. - [ ] Extract narrowly scoped pure helpers where necessary to make business rules testable. **Acceptance:** deterministic tests cover both successful and failure paths without a live backend. Assertions describe business outcomes, including configuration preservation and correct namespace targeting. ### 3. Add component and page interaction regression tests — P1 - [ ] Establish reusable render helpers for Dva/store, routing, internationalization, and controlled API responses. - [ ] Cover one representative selector/rule or plugin configuration form: create, edit initialization, validation, and submission. - [ ] Verify a rejected save/delete does not show success or incorrectly update the displayed data. - [ ] Verify namespace switching refreshes the relevant data and permissions. - [ ] Verify permission-dependent menus/buttons and handling of direct navigation to restricted routes. **Acceptance:** tests exercise user-visible interactions and submitted payloads; they run without a live backend and include error/empty states. Frontend permission tests do not substitute for backend authorization checks. ### 4. Add critical browser E2E workflows — P1 - [ ] Set up Playwright with an isolated ShenYu Admin environment, an explicitly pinned compatible backend version, health checks, test accounts, and reproducible seed/cleanup scripts. - [ ] Cover login/logout and expired-session behavior. - [ ] Cover a selector/rule lifecycle: create, edit, disable/enable, and delete. - [ ] Cover plugin configuration save and re-open/refresh. - [ ] Add an unchanged-edit/save regression test: read stored configuration, open and save without changes, then compare the stored result, accounting explicitly for server-managed or write-only fields. - [ ] Cover namespace switching so displayed resources and subsequent writes target the selected namespace. - [ ] Add targeted browser scenarios with injected 401/network failures to verify error UX; distinguish these from real-backend E2E checks. **Acceptance:** core workflows run against a disposable backend, verify persistence beyond success notifications, and clean up test data. Use condition/response-based waits and stable locators. Failures retain useful screenshots, traces, and service logs. Start with roughly 5–10 critical workflows rather than every page. ### 5. Complete CI integration and contributor guidance — P2 - [ ] Run unit and interaction tests on relevant PRs; add a small E2E smoke suite once the environment is reliable. - [ ] Schedule the broader E2E suite and document how to run it manually. - [ ] Document commands, fixture management, backend version alignment, and failure diagnosis. - [ ] Establish the convention that a business bug fix includes an appropriate regression test. - [ ] Publish an initial coverage baseline and grow coverage around changed, high-risk code; decide any thresholds after measuring the baseline. **Acceptance:** contributors can reproduce CI tests locally; CI failures expose actionable artifacts; the new suites participate in the project's checks. Any required-check/branch-protection configuration is coordinated with maintainers. ## Reference implementations - **APISIX Dashboard:** Vitest for logic tests and Playwright for business/regression flows; E2E CI starts services with Docker Compose. Particularly relevant examples are [unchanged edit/save preserves configuration](https://github.com/apache/apisix-dashboard/blob/fa2fd0f60f8afffb096476333b9ba63b4c518fa3/e2e/tests/regression/form.round-trip-invariant.spec.ts) and [401 must not produce a success toast](https://github.com/apache/apisix-dashboard/blob/fa2fd0f60f8afffb096476333b9ba63b4c518fa3/e2e/tests/regression/auth.401-no-false-success.spec.ts). See its [E2E workflow](https://github.com/apache/apisix-dashboard/blob/fa2fd0f60f8afffb096476333b9ba63b4c518fa3/.github/workflows/e2e.yml). - **SkyWalking Booster UI:** Vitest/Vue Test Utils tests for components, hooks, routing, and utilities, with [unit tests in CI](https://github.com/apache/skywalking-booster-ui/blob/2d2eeb4da79a96d356bd4bd0e7c44d61a850b5a5/.github/workflows/nodejs.yml). Its Cypress directory contains a scaffold example, so it should not be treated as a business E2E reference. - **SkyWalking Horizon UI:** [scenario-based E2E CI](https://github.com/apache/skywalking-horizon-ui/blob/dc31135cadee387263931f359819e7a8c7971bdc/.github/workflows/e2e.yaml) runs against real service dependencies and uses [Playwright with failure artifacts](https://github.com/apache/skywalking-horizon-ui/blob/dc31135cadee387263931f359819e7a8c7971bdc/test/e2e/playwright/playwright.config.ts). The goal is incremental regression protection for ShenYu's actual workflows, with small reviewable changes and a reliable CI baseline. -- 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]
