Tech debt: Create "integration tests" for resources API

[aalves08]

Is your feature request related to a problem? Please describe.

The current unit tests for the resources API resources-api-class.test.ts mock the store. We should create more involved testing where we use the actual store.

Main challenges:
Store setup boilerplate. The dashboard-store module has a lot of state/getters/mutations/actions. You'd need to register the module and populate enough state for the actions to not blow up — at minimum: schemas, type registrations, and the config.namespace that prefixes store paths.

Schema seeding. Actions like findLabelSelector check paginationEnabled, schemaFor, normalizeType, typeRegistered — these all depend on state being pre-populated. You'd need to commit schemas and resource counts before the test runs.

Two code paths. for findLabelSelector branches on paginationEnabled(). You'd want tests for both: SSP enabled (routes to findPage with FilterArgs) and SSP disabled (routes to findMatching with string selector). That means two test setups with different store configurations.

The request action is the natural mock boundary. Everything above it is routing logic, everything below it is HTTP. Mocking at this level gives you real coverage of the arg transformation chain without needing a running server.

Describe the solution you'd like

Describe alternatives you've considered

Additional context

[github-actions]

🎯 Agentic Issue Triage

Summary: This is a tech debt enhancement request to create integration-style unit tests for the findLabelSelector action in shell/plugins/dashboard-store/actions.js. Currently, the existing tests mock the store entirely; this issue asks for tests that wire up a real (or near-real) Vuex store to cover the full argument-transformation logic — including both SSP-enabled and SSP-disabled code paths — without requiring a running server.

---

📂 Relevant Files

File	Role
shell/plugins/dashboard-store/actions.js	Contains findLabelSelector, findPage, findMatching — the functions to be covered
shell/plugins/dashboard-store/getters.js	Contains paginationEnabled (line ~550) — key branching getter
shell/plugins/dashboard-store/__tests__/actions.test.ts	Existing action tests (mock-only) — reference for test structure
shell/plugins/dashboard-store/__tests__/utils/store-mocks.ts	Shared mock utilities
shell/types/store/dashboard-store.types.ts	Type definitions for ActionFindLabelSelectorArgs, ActionFindPageArgs, ActionFindMatchingArgs

The referenced test file resources-api-class.test.ts does not yet exist and is the artefact to be created.

🔍 Technical Analysis

findLabelSelector (actions.js ~line 556) has the following shape:

async findLabelSelector(ctx, { type, matching: { namespace, labelSelector }, opt }) {
  if (getters['paginationEnabled']?.()) {
    // SSP path → dispatch('findPage', { ... FilterArgs ... })
  }
  // Non-SSP path → dispatch('findMatching', { type, selector, opt, namespace })
}
```

**Key decision point:** `paginationEnabled()` getter drives the branch. Tests must exercise both `true` and `false` states.

**Natural mock boundary:** The `request` action is the right boundary — everything from `findLabelSelector` → `findPage`/`findMatching` → `request` is pure routing/arg-transformation logic. Mock `request` only; let the rest run against real store logic.

**Minimal store state needed (per the issue author):**
- `schemas` — seeded with at least the type under test
- `type registrations` — so `typeRegistered`, `normalizeType` resolve correctly
- `config.namespace` — prefixes store module paths (e.g. `'management'`)
- A `paginationEnabled` configuration flag (toggled per test suite)

</details>

<details>
<summary>🧪 Suggested Test Structure</summary>

```
shell/plugins/dashboard-store/__tests__/resources-api-class.test.ts

Suite 1 – SSP Disabled (paginationEnabled = false)

• findLabelSelector dispatches findMatching with the correct selector string (from labelSelectorToSelector())
• Namespace is forwarded correctly
• Result is returned as-is (non-transient)
• Result is { data: ... } when opt.transient = true

Suite 2 – SSP Enabled (paginationEnabled = true)

• findLabelSelector dispatches findPage with a FilterArgs object built from labelSelector
• Throws an error when labelSelector is empty
• transient defaults to false (avoids watch/cache side effects)
• Namespace is passed as namespaced

Store setup pattern (recommended):

import Vuex from 'vuex';
import dashboardStoreModule from '`@shell/plugins`/dashboard-store';

function createTestStore({ paginationEnabled = false, schemas = [] } = {}) {
  // Register module, seed state, mock only `request`
}

Reference shell/plugins/dashboard-store/__tests__/utils/store-mocks.ts — extend it or replicate the pattern for the new integration setup.

💡 Implementation Nudges

1. Existing test patterns to follow: shell/plugins/dashboard-store/__tests__/actions.test.ts shows how findMatching is currently tested with mocks; the new file should evolve that pattern toward a real store registration.

2. paginationEnabled is a getter (getters.js:550) that reads from rootGetters and store state — toggling it for the two suites may require either injecting a different root state or directly stubbing that one getter while keeping everything else real.

3. FilterArgs class is used inside the SSP branch — ensure it is importable in the test environment (check for any circular dependency issues).

4. labelSelectorToSelector utility converts a kube LabelSelector object to a string — the non-SSP tests should assert the transformed string value is what findMatching receives.

5. Use jest.fn() only for request — all other actions should run real code so the integration value is preserved.

📋 Implementation Checklist

• Create shell/plugins/dashboard-store/__tests__/resources-api-class.test.ts
• Write helper createTestStore() that registers the dashboard-store module with minimal viable state
• Write SSP-disabled suite (paginationEnabled = false) covering all findMatching routing cases
• Write SSP-enabled suite (paginationEnabled = true) covering all findPage routing cases, including empty-labelSelector error
• Ensure request is the only action mocked — verify with jest.spyOn
• Run yarn test:ci shell/plugins/dashboard-store/__tests__/resources-api-class.test.ts and confirm green
• Run yarn lint on the new file

📚 Relevant Resources

• [Vuex testing guide]((v3.vuex.vuejs.org/redacted) — registering modules and seeding state in tests
• [Jest mock boundaries]((jestjs.io/redacted) — jest.spyOn on Vuex dispatch
• Related issue: Tech debt: Create compatibility tests for extensions (v2) #17237 (Tech debt: Create compatibility tests for extensions) — similar test-infrastructure work in the same repo

Note

🔒 Integrity filter blocked 3 items

The following items were blocked because they don't meet the GitHub integrity level.

• #10097 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• [.backport v2.13.6] Move WindowManager to App root #17375 list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
• [.backport v2.14.2] Move WindowManager to App root #17374 list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".

To allow these resources, lower min-integrity in your GitHub frontmatter:

tools:
  github:
    min-integrity: approved  # merged | approved | unapproved | none

Generated by Agentic Triage for issue #17424 · ● 774.3K · ◷