testing-api-overrides

Testing API Overrides

Test that your code sends correct API parameters by using conditional overrides that respond differently based on the request. This approach tests actual user-facing behavior rather than inspecting internal request details.

Philosophy

Good tests verify what users see, not implementation details.

Instead of:

1. ❌ Recording the request and checking query params
2. ❌ Asserting on internal function calls

Do this:

1. ✅ Set up conditional mocks that respond based on params
2. ✅ Verify the component renders the expected data

If the code sends wrong parameters, the mock returns wrong data, the UI shows wrong content, and the test fails. This catches real bugs.

When to Use Conditional Overrides

• Testing list filtering (e.g., filter by group, status, search term)
• Testing pagination parameters
• Testing sort order
• Any read operation where request parameters affect what data is returned

Note: For mutations (create/update/delete), use recordRequests() instead. See the testing-api-assertions skill.

conditionalOverride()

Returns different data based on request properties:

import { mockedGetApiV1BetaWorkloads } from '@mocks/fixtures/workloads/get'

mockedGetApiV1BetaWorkloads.conditionalOverride(
  // Predicate: when should this override apply?
  ({ query }) => query.group === 'archive',
  // Transform: what data to return?
  (data) => ({
    ...data,
    workloads: [], // Archive group is empty
  })
)

Predicate Function

The predicate receives parsed request info with easy access to query params, path params, body, and headers:

;({ query, path, body, headers }) => {
  // Query parameters (pre-parsed)
  query.group // '?group=archive' -> 'archive'
  query.status // '?status=running' -> 'running'

  // Path parameters (from route like /workloads/:name)
  path.name // for /workloads/:name

  // Request body (for POST/PUT/DELETE)
  body?.name // parsed JSON body

  // Headers
  headers.get('Authorization')

  return true // or false
}