Token导航 LogoToken导航TokenDH.com
前端设计操作浏览器github未标认证来源可访问许可证需确认审计提醒

api-testingAPI 测试

Agent Skill

用于辅助 API 设计、接口文档、请求响应结构和服务集成说明。它适合让 Agent 梳理 endpoint、生成 OpenAPI 草稿、检查字段命名、整理错误码或辅助前后端联调。使用时需要确认真实业务语义、鉴权方式、分页和错误处理规则;涉及生成接口文档时,应避免凭空补字段,最好从现有代码、schema 或接口样例中提取事实。

总安装

396

周安装

16

GitHub Stars

公开资料未说明

下载量

124
CodexClaudeCursorGemini CLI

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

2

许可证

unknown

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:api-testing(API 测试)
来源仓库:https://github.com/help-me-test/skills
仓库路径:skills/api-testing
安装命令:
npx skills add https://github.com/help-me-test/skills --skill api-testing
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

skills.shnpx skills
npx skills add https://github.com/help-me-test/skills --skill api-testing

简介

api-testing 用于辅助 API 设计、接口文档生成和前后端联调支持,适合梳理 endpoint、检查字段命名或整理错误码。

  • 适用于需要生成 OpenAPI 草稿、验证请求响应结构或优化服务集成的开发场景。
  • 使用时需结合现有代码、schema 或接口样例提取事实,避免凭空补字段或忽略鉴权方式。
  • 涉及接口文档生成时应确认业务语义、分页规则和错误处理机制,确保输出符合真实需求。
  • 适用宿主包括 Codex、Claude、Cursor、Gemini CLI,接入前应确认版本、权限和运行环境要求。

SKILL.md

### 🔴 YOU WRITE THE TEST FIRST. Changed code → run the tests. New feature → write the test before the code. The test is the spec. The test is done when it's green. No test = not done.

API Testing with HelpMeTest

The API library runs HTTP requests inside the active browser tab. This means the browser's session cookies, auth headers, and credentials are sent automatically — no token juggling.

A live httpbin instance is available for examples and exploration: https://httpbin.playground.helpmetest.com

The Golden Rule

Authenticate with As <StateName> FIRST, then make API calls. The browser session carries everything.

As    Admin
Go To    https://app.example.com
GET    /api/users
Response Status Should Be    200

Never re-authenticate inside a test. Never manually copy tokens. The browser already has them.

HTTP Verbs

GET

Go To    https://httpbin.playground.helpmetest.com
GET    /get
Response Status Should Be    200
Field Should Exist    url

GET    /get    headers={"X-Custom-Header": "hello"}
Field Should Exist    headers.X-Custom-Header

POST

Go To    https://httpbin.playground.helpmetest.com
POST    /post    body={"name": "Alice", "role": "editor"}
Response Status Should Be    200
Field Equals    json.name    Alice
Field Equals    json.role    editor

PUT / PATCH

PUT    /put    body={"name": "Alice Updated"}
Response Status Should Be    200
Field Equals    json.name    Alice Updated

PATCH    /patch    body={"email": "new@example.com"}
Response Status Should Be    200
Field Equals    json.email    new@example.com

DELETE

DELETE    /delete
Response Status Should Be    200

POST Form (application/x-www-form-urlencoded)

POST Form    /post    fields={"username": "alice", "password": "secret"}
Response Status Should Be    200
Field Equals    form.username    alice

POST Multipart (file upload)

# File on disk
POST Multipart    /post    files={"avatar": "/tmp/photo.png"}
Response Status Should Be    200

# Inline base64 — no file on disk needed
POST Multipart    /post
...    fields={"title": "Report"}
...    files={"file": {"base64": "SGVsbG8gV29ybGQ=", "filename": "hello.txt", "content_type": "text/plain"}}
Response Status Should Be    200
Field Should Exist    files.file

CURL — paste directly from DevTools

CURL    curl 'https://httpbin.playground.helpmetest.com/get' -H 'X-My-Header: test'
Response Status Should Be    200
Field Should Exist    headers.X-My-Header

Right-click any network request in DevTools → "Copy as cURL" → paste. The library replaces the cookies in the copied command with the live browser session automatically.

URL Rules

  • Relative /api/users — resolved against the current page origin. The browser must already be at the target site (via Go To or As).
  • Absolute https://httpbin.playground.helpmetest.com/get — works from any page, no prior navigation needed.
  • Same-origin APIs — use relative URLs after navigating to the app; no CORS concerns.
  • Cross-origin APIs — use absolute URLs; the server must allow credentials: include CORS requests.

Asserting the Response

Status

Go To    https://httpbin.playground.helpmetest.com
GET    /status/200
Response Status Should Be    200

GET    /status/404
Response Status Should Be    404

GET    /status/500
Response Status Should Be    500

Body text (raw string match)

GET    /get
Response Body Should Contain    "url"
Response Body Should Not Contain    error

Partial object match (Karate-style)

Checks that the response *contains* the expected structure. Extra fields are ignored.

GET    /get
Response Body Should Match    {"url": "#string", "headers": "#object"}

POST    /post    body={"name": "Alice"}
Response Body Should Match    {"json": {"name": "Alice"}, "url": "#string"}

Type placeholders: | #string | any string (including empty) | | #number | any integer or float | | #boolean | true or false | | #array | any JSON array | | #object | any JSON object | | #null | JSON null | | #notnull | any non-null value | | #present | key exists (value may be null) | | #ignore | skip this field entirely |

Field assertions (dot-path)

Navigate nested JSON with . and array indices with .N:

GET    /get    headers={"X-App": "myapp"}
Field Equals    headers.X-App    myapp
Field Should Exist    headers.Host
Field Should Not Exist    headers.X-Nonexistent

POST    /post    body={"score": 42, "tags": ["a", "b", "c"]}
Field Equals    json.score    42
Field Equals    json.tags.0    a
Field Equals    json.tags.2    c
Field Greater Than    json.score    0
Field Less Than    json.score    100
Field Greater Or Equal    json.score    42
Field Less Or Equal    json.score    42

POST    /post    body={"message": "hello world"}
Field Contains    json.message    hello
Field Not Contains    json.message    error
Field Starts With    json.message    hello
Field Ends With    json.message    world

POST    /post    body={"uuid": "abc-123-def"}
Field Matches Regexp    json.uuid    ^[a-z]+-\\d+-[a-z]+$

POST    /post    body={"status": "active"}
Field Should Be One Of    json.status    active,pending,inactive

Field type checks

POST    /post    body={"name": "Alice", "score": 99, "active": true, "tags": [], "meta": {}}
Field Type Should Be    json.name    string
Field Type Should Be    json.score    number
Field Type Should Be    json.active    boolean
Field Type Should Be    json.tags    array
Field Type Should Be    json.meta    object

Array and string length

POST    /post    body={"tags": ["a", "b", "c"]}
Field Length Should Be    json.tags    3

POST    /post    body={"items": []}
Field Should Be Empty    json.items

POST    /post    body={"items": [1, 2]}
Field Should Not Be Empty    json.items

When the response root is an array, use ${EMPTY} as the field path:

# hypothetical endpoint returning a JSON array
GET    /json-array-endpoint
Field Length Should Be    ${EMPTY}    5
Field Each Should Match    ${EMPTY}    {"id": "#number"}

Array item matching

Assert every item in an array matches a pattern:

POST    /post    body={"users": [{"id": 1, "name": "Alice"}, {"id": 2, "name": "Bob"}]}
Field Each Should Match    json.users    {"id": "#number", "name": "#string"}

Empty / not empty

POST    /post    body={"errors": [], "data": [1, 2, 3]}
Field Should Be Empty    json.errors
Field Should Not Be Empty    json.data

Response headers

GET    /response-headers?Content-Type=application/json
Response Header Should Be    content-type    application/json
Response Header Should Contain    content-type    json

Response time

GET    /get
Response Time Should Be Less Than    2000

# httpbin /delay/N endpoint adds N seconds — use to test timeout thresholds
GET    /delay/1
Response Time Should Be Less Than    3000

Extracting Values to Chain Requests

Get Response Field returns a value for use in the next request — the standard pattern for dependent calls.

POST    /post    body={"name": "Alice"}
Response Status Should Be    200
${name}=    Get Response Field    json.name
# ${name} == "Alice"

GET    /get    headers={"X-Echo": "${name}"}
Field Equals    headers.X-Echo    Alice
${status}=    Get Response Status
${body}=      Get Response Body
Log    ${body}

Standard CRUD Pattern

The typical shape for testing any CRUD resource:

*** Test Cases ***
Create Read Update Delete User
    As    Admin
    Go To    https://app.example.com

    # Create
    POST    /api/users    body={"name": "Alice", "role": "editor"}
    Response Status Should Be    201
    ${id}=    Get Response Field    id

    # Read
    GET    /api/users/${id}
    Field Equals    name    Alice
    Field Equals    role    editor

    # Update
    PATCH    /api/users/${id}    body={"name": "Alice Updated"}
    Response Status Should Be    200
    Field Equals    name    Alice Updated

    # Delete
    DELETE    /api/users/${id}
    Response Status Should Be    204

    # Verify gone
    GET    /api/users/${id}
    Response Status Should Be    404

Error Scenarios

Always test the unhappy paths:

Go To    https://httpbin.playground.helpmetest.com

# 404
GET    /status/404
Response Status Should Be    404

# 500
GET    /status/500
Response Status Should Be    500

# App-level: missing required field
As    Admin
Go To    https://app.example.com
POST    /api/users    body={"role": "editor"}
Response Status Should Be    400
Field Should Exist    error

# Unauthorized (no session)
GET    /api/admin/secrets
Response Status Should Be    401

# Forbidden (wrong role)
As    RegularUser
POST    /api/admin/users    body={"name": "Bob"}
Response Status Should Be    403

Contract Testing

API contracts ensure that when your backend changes, consumers (frontend, mobile, other services) don't silently break. HelpMeTest's API library has everything you need — no Pact Broker required.

The Core Idea

A contract test answers: "If this endpoint changes, will I know before users do?"

Test from the consumer's perspective — only assert what the consumer actually uses. Extra fields are fine; missing fields break consumers.

Define a Contract with Response Body Should Match

Use type placeholders to lock the shape without hardcoding values:

*** Test Cases ***
User API contract — consumer perspective
    As    Admin
    Go To    https://app.example.com

    GET    /api/users/1
    Response Status Should Be    200
    # Consumer needs: id, name, email — assert exactly those
    Response Body Should Match    {
    ...    "id": "#number",
    ...    "name": "#string",
    ...    "email": "#string"
    ...    }
    # Extra fields ignored — contract is about what consumer needs

Backward Compatibility: Fields Must Not Disappear

*** Test Cases ***
GET /api/orders — backward compatibility
    As    User
    Go To    https://app.example.com

    GET    /api/orders
    Response Status Should Be    200
    # These fields existed before v2 — they must still exist
    Field Should Exist    0.id
    Field Should Exist    0.status
    Field Should Exist    0.total
    Field Should Exist    0.created_at
    # New field added in v2 — that's fine, consumers ignore it
    # Field Should Exist    0.metadata   ← don't assert new fields yet

Error Response Contract

Error responses have a contract too — clients parse them:

*** Test Cases ***
Error responses follow contract
    As    User
    Go To    https://app.example.com

    # 400 — validation error must include field-level details
    POST    /api/users    body={"name": ""}
    Response Status Should Be    400
    Field Should Exist    error
    Field Should Exist    error.message
    # If client parses error.fields, it must always be present
    Field Should Exist    error.fields

    # 404 — not found must include message
    GET    /api/users/nonexistent-id
    Response Status Should Be    404
    Field Should Exist    error.message

Testing API Evolution (Adding Fields is Safe, Removing is Not)

*** Test Cases ***
Adding optional field does not break existing consumers
    As    Admin
    Go To    https://app.example.com

    POST    /api/products    body={"name": "Widget", "price": 9.99}
    Response Status Should Be    201
    ${id}=    Get Response Field    id

    # Old contract — must still work
    Response Body Should Match    {"id": "#number", "name": "#string", "price": "#number"}

    # New field present but consumer doesn't need it — use #ignore
    Response Body Should Match    {"id": "#number", "name": "#string", "metadata": "#ignore"}

Chaining Contract Tests (Consumer Workflow)

Test the full consumer workflow — not just individual endpoints:

*** Test Cases ***
Checkout flow API contract
    As    User
    Go To    https://app.example.com

    # Step 1: Add to cart — consumer needs cart id
    POST    /api/cart    body={"product_id": 1, "quantity": 2}
    Response Status Should Be    201
    ${cart_id}=    Get Response Field    id
    Field Type Should Be    id    number

    # Step 2: Get cart — consumer needs items array with price
    GET    /api/cart/${cart_id}
    Response Body Should Match    {"id": "#number", "items": "#array", "total": "#number"}
    Field Should Not Be Empty    items

    # Step 3: Checkout — consumer needs order id for confirmation page
    POST    /api/orders    body={"cart_id": "${cart_id}"}
    Response Status Should Be    201
    Field Should Exist    id
    Field Should Exist    status
    Field Should Be One Of    status    pending,confirmed

What Makes a Good API Contract Test

  • Assert structure, not specific values — use type placeholders, not exact IDs
  • Assert what consumers use — if the frontend only reads id and name, only assert those
  • Always test error contracts — clients parse errors, those need contracts too
  • Test status codes explicitlyResponse Status Should Be before any field assertions
  • Chain requests for real consumer flows — a consumer rarely calls one endpoint in isolation

Common Pitfalls

Don't use Javascript fetch in tests. The API library exists precisely so you don't have to. Javascript fetch(...) bypasses auth, skips rrweb recording, and produces brittle tests.

Relative URLs require the browser to be at the site. Always pair with As <StateName> + Go To at the top. Without navigation, the relative URL resolves against whatever origin the browser last visited.

Body is a JSON string. Pass body={"key": "value"} as a literal — Robot Framework passes it through as-is. The library serializes Python dicts automatically, but always write the body as a JSON string literal in tests.

httpbin echoes what you send. When testing against httpbin.playground.helpmetest.com, JSON body fields come back under .json, form fields under .form, files under .files, and query params under .args. So POST /post body={"name":"Alice"} → assert json.name, not name.

适合场景

01

用户想查找某类 Agent Skill 时

02

需要根据任务场景推荐可安装能力包时

03

需要对比不同来源的安装命令和来源信息时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

Codex

32.09%
按下载量换算40

Claude

31.2%
按下载量换算39

Cursor

19.31%
按下载量换算24

Gemini CLI

9.09%
按下载量换算11

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

可疑

权限和风险

操作浏览器

该 Skill 可能涉及浏览器控制能力,使用时可能读取或操作网页内容,需要在受控环境中确认权限边界。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。来源安全扫描存在 warning/failed 结果,不能写成本站确认安全。当前只有一个来源,正式发布前建议补源仓库或其他目录站核验。

来源信息

继续浏览同类 Skills