2nd Task list No. 4 - Debora

[MuhammadKhalilzadeh]

Debora — Full-Stack / QA & Testing 2nd Checklist

Focus: quality, testability, and CI stability. These tasks deliberately span frontend, backend, and Python services so you can own quality across the whole stack rather than only one layer.

---

• 1. Re-enable and stabilize one critical end-to-end journey

  Almost every Playwright spec under Clients/e2e/ is currently skipped. Pick the most critical user journey — login as super-admin → create an organization → create a project → add a risk → open the Tasks page and verify the Deadline Warning banner — and remove the test.skip() blocks that block it. Update fixtures, page objects, and the global setup so the test can run reliably both locally and in CI.

  On the backend side, add a lightweight smoke test that seeds the same state (org, project, risk, task with due dates) and calls the deadline-summary endpoint to confirm the counts the E2E test expects. This gives you a backend contract test and an E2E test that share the same factory data.

  Acceptance: The chosen journey passes three consecutive local runs; the backend smoke test passes in npm test; no test relies on real timers or network calls.

• 2. Add backend integration tests for the file-manager module

  Servers/tests/integration/ has no coverage for file uploads, folders, tagging, or deletion. Build integration tests for POST /api/files/upload, GET /api/files, PATCH /api/files/:id/tags, and DELETE /api/files/:id using the existing integration setup and database transactions for isolation. Mock object storage (S3/local) so the tests do not require real cloud credentials.

  On the frontend, add MSW handlers in Clients/src/test/mocks/handlers.ts for the same file-manager operations, including success, empty-list, validation-error, and 403-forbidden variants. Use them to add a simple smoke test for the file-manager page that renders loading, empty, and populated states.

  Acceptance: Integration tests pass and roll back data between cases; MSW handlers cover the four operations; frontend smoke test renders all three states without hitting a real backend.

• 3. Expand MSW handler coverage for under-mocked domains

  The current MSW handler suite is missing Shadow AI, AI Detection scans/repositories, compliance frameworks, settings, invitations, and bulk-update endpoints. Add handlers for these domains so that unit and integration tests can exercise them without real network traffic. Use faker-based factories for realistic payloads and include error variants (400 validation, 403 forbidden, 500 server error) so tests can verify error boundaries.

  On the backend, verify that the request bodies your handlers expect match the actual route contracts by running a quick contract check against the backend routes or swagger.yaml. If you find drift, open a follow-up task rather than fixing it in scope, but document the discrepancy.

  Acceptance: At least five new domain groups have handlers; each group has success and error variants; no real network requests fire during frontend test runs; drift findings are documented.

• 4. Add controller tests for high-priority untested modules

  Controllers such as approvalRequest.ctrl.ts, automations.ctrl.ts, fileManager.ctrl.ts, aiTrustCentre.ctrl.ts, advisor.ctrl.ts, shadowAi.ctrl.ts, and postMarketMonitoring.ctrl.ts have little or no test coverage. Use the existing supertest + jest patterns in Servers/controllers/__tests__ and mock the database layer via the project’s helpers. Cover create, read, update, authorization, and validation-error paths for each target.

  On the frontend, for the same domains, add component or hook tests that verify the UI behaves correctly when these controllers return the error shapes you just tested. This pairs backend error cases with frontend handling and prevents regressions on both sides.

  Acceptance: Each target controller has create/read/update/auth tests passing in npm test; at least one frontend test per domain exercises the corresponding error state.

• 5. Add frontend unit tests for shared component directories

  Drawer, Inputs/Select, Modals/StandardModal, and Table/ExportMenu are reused across the product but have no root-level __tests__ folders. Add React Testing Library tests for rendering, user interactions, accessibility properties, and keyboard behavior. Use @testing-library/user-event and avoid brittle snapshot tests.

  On the backend, add corresponding unit tests for the utility functions these components rely on, such as table-export formatting and date formatting utilities. If a shared utility is untested, cover it so the frontend and backend tests share the same source-of-truth logic.

  Acceptance: Each shared component directory has at least one meaningful test; line coverage for presentation/components/Drawer, Inputs, Modals, and Table rises; backend utility tests pass.

• 6. Build a reusable cross-tenant isolation test matrix

  Create a test harness under Servers/tests/integration/tenant-isolation/ that sets up two organizations, two users, and a set of shared entity types. Write parameterized tests that prove User A cannot list, read, update, or delete Organization B’s projects, files, risks, or tasks. Make the matrix easy to extend so adding a new entity type is a one-line change.

  On the frontend, add an MSW middleware that rejects cross-organization requests with a 403 and write a test that confirms the UI shows the error toast or boundary instead of rendering foreign data. This proves the isolation contract is honored all the way to the screen.

  Acceptance: Matrix covers at least four entity types and CRUD operations; tests pass in CI; frontend MSW scenario exists; documentation explains how to add new entities.

• 7. Introduce OpenAPI contract tests for priority routes

  Pick ten high-traffic backend routes and validate their responses against Servers/swagger.yaml using jest-openapi or a lightweight JSON Schema validator. Focus on routes used by the dashboard, projects, tasks, risks, and files. Document any drift (missing security spec, wrong field types, missing 404/403 responses) as follow-up tasks.

  On the frontend, use the same OpenAPI spec to generate or tighten TypeScript DTOs for those ten routes in the repository layer. This reduces any usage and gives the contract tests a direct impact on frontend type safety.

  Acceptance: Contract tests run in npm test and fail on schema violations; ten routes covered; frontend DTOs for those routes are typed and typecheck passes.

• 8. Audit and stabilize flaky tests across the stack

  Review the existing frontend and backend test suites for real timers, unawaited promises, missing waitFor, non-deterministic data, and tests asserting on console.log. Fix the worst offenders first, focusing on async hook tests, dashboard metric tests, and integration tests that rely on fixed dates. Replace setTimeout in tests with vi.advanceTimersByTimeAsync or jest.advanceTimersByTimeAsync where appropriate.

  On the backend, look for tests that assert on log output or depend on the order of database rows without an explicit ORDER BY. Stabilize them and add a CI check that runs the test suite three times in a row without retries to prove flakiness is gone.

  Acceptance: Test suite passes three consecutive local/CI runs without retries; no test uses real network/time; flaky-test tracker documents root causes and fixes.

• 9. Add accessibility E2E scans with axe-core

  Integrate @axe-core/playwright into the E2E suite and scan key pages: Dashboard, Tasks, ModelInventory, Vendors, and Policies. Fail the test on critical or serious violations and attach an accessibility report artifact in CI. Where violations are false positives or require design input, document them with a suppression comment rather than ignoring them.

  On the backend, ensure the pages you scan have consistent HTML semantics by adding a small validation test that checks for a single <main> landmark, valid heading order, and labels on server-rendered public pages (intake forms, share-link views). This links frontend accessibility to the data the backend serves.

  Acceptance: Scans run as part of test:e2e; zero critical/serious issues on the scanned pages; report artifact is produced in CI; backend semantic-HTML test passes.

• 10. Add unit tests for AIGateway core services

  The AIGateway test suite currently logs into a live Node backend and makes real HTTP calls. Add a AIGateway/tests/unit/ suite that mocks the database, Redis, and LiteLLM and exercises cost_service, guardrail_service, cache_service, and proxy_service. Cover budget enforcement, rate-limit rejection, ACL checks, guardrail blocking, cache-key collision, and provider error mapping.

  On the Node side, add a small integration test that calls the AIGateway proxy through the internal route and verifies the response shape matches what the frontend AIGateway/SpendDashboard expects. This connects Python service behavior to the frontend consumption layer.

  Acceptance: Unit tests run in isolation without real credentials; budget, ACL, guardrail, and cache logic are covered; Node integration test verifies the proxy response shape; CI runs the new suite.