agentleFS
stacklokstacklok/toolhive-studio/.cursor/skills/testing-api-assertions/SKILL.md

testing-api-assertions

Skill173 starsChanged 5 months agoApache-2.0View on GitHub

Verify API requests in tests. Use when testing that correct API calls are made for create, update, or delete operations. Use when testing mutations, form submissions, or actions with backend side effects.

The file

We split this skill into the rules it gives an agent

4 rules. About 0 are common, 2 are distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈2

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Verify that your code sends the correct API requests for operations with side effects.

    line 8
  2. Very specific:

    Use recordRequests() to capture all API requests made during a test:

    line 27
  3. Distinctive:

    Call it at the start of your test, before triggering actions

    line 128
  4. Very specific:

    Use toMatchObject() for partial matching when payload has extra fields

    line 130

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Testing API Assertions

Verify that your code sends the correct API requests for operations with side effects.

When to Use Request Assertions

DO use for operations with side effects:

  • Creating resources (POST)
  • Updating resources (PUT/PATCH)
  • Deleting resources (DELETE)
  • Any mutation that changes backend state

DON'T use for read operations:

  • Fetching data (GET)
  • For these, just verify the component displays the data correctly
  • The mock API is not stateful, so verifying GET requests adds no value

recordRequests()

Use recordRequests() to capture all API requests made during a test:

import { recordRequests } from '@/common/mocks/node'

it('creates a group with correct payload', async () => {
  const rec = recordRequests()

  // ... perform action that triggers API call ...
  await userEvent.click(screen.getByRole('button', { name: /create/i }))

  // Find the request
  const request = rec.recordedRequests.find(
    (r) => r.method === 'POST' && r.pathname === '/api/v1beta/groups'
  )

  // Assert it was made with correct data
  expect(request).toBeDefined()
  expect(request?.payload).toEqual({ name: 'my-group' })
})

Recorded Request Shape

Each recorded request contains:

{
  pathname: '/api/v1beta/groups',      // URL path
  method: 'POST',                       // HTTP method
  payload: { name: 'my-group' },        // Parsed JSON body (if present)
  search: { filter: 'active' },         // Query parameters
}

Common Patterns

Verify POST payload

const rec = recordRequests()

// ... trigger create action ...

const createRequest = rec.recordedRequests.find(
  (r) => r.method === 'POST' && r.pathname === '/api/v1beta/workloads'
)
expect(createRequest?.payload).toMatchObject({
  name: 'my-server',
  group: 'default',
})

Verify DELETE was called

const rec = recordRequests()

// ... trigger delete action ...

const deleteRequest = rec.recordedRequests.find(
  (r) =>
    r.method === 'DELETE' && r.pathname === '/api/v1beta/workloads/my-server'
)
expect(deleteRequest).toBeDefined()

Verify request order

const rec = recordRequests()

// ... trigger actions ...

const postRequests = rec.recordedRequests.filter((r) => r.method === 'POST')
const groupIndex = postRequests.findIndex((r) => r.pathname.includes('/groups'))
const workloadIndex = postRequests.findIndex((r) =>
  r.pathname.includes('/workloads')
)

// Group must be created before workload
expect(groupIndex).toBeLessThan(workloadIndex)

Verify request count

const rec = recordRequests()

// ... trigger batch action ...

const deleteRequests = rec.recordedRequests.filter(
  (r) =>
    r.method === 'DELETE' && r.pathname.startsWith('/api/v1beta/workloads/')
)
expect(deleteRequests).toHaveLength(3)

Important Notes

  • recordRequests() clears previous recordings when called
  • Call it at the start of your test, before triggering actions
  • Each test starts fresh - recordings don't persist between tests
  • Use toMatchObject() for partial matching when payload has extra fields

When NOT to Use This

For read operations (GET) where you need to verify query parameters are sent correctly, don't use recordRequests(). Instead, use conditional overrides that return different data based on params, then verify the UI shows the expected data. See testing-api-overrides skill.

This approach is more robust because it tests actual user-facing behavior.

Related Skills

  • testing-with-api-mocks - Auto-generated mocks and fixture basics
  • testing-api-overrides - Conditional responses for testing filters/params (read operations)

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.