跳到正文
cccskills
免费在 GitHub 公开中文介绍

writing-acceptance-tests

编写或修改 GitHub CLI 验收测试时,帮助选择仓库夹具、安排资源清理、控制 API 请求量,并为异步工作流设置条件等待,再先集中验证改动的测试。

原文查看原文说明

Use when adding or changing GitHub CLI acceptance tests, txtar scripts, testdata groups, repository fixtures, or acceptance harness behavior.

cli/cli星标 46,752(GitHub 46,752 + cccskills 0)
集成工具GitHub

实测评分 未实测

查看安装方法

适用场景

  • 为 GitHub CLI 添加验收测试
  • 选择测试使用的仓库夹具
  • 等待工作流满足运行条件
  • 控制验收测试的 API 请求量

中文介绍

功能

此技能帮助编写或修改针对真实 GitHub 资源运行 GitHub CLI(gh)的验收测试。每项测试都要确定是否需要用户权限凭据,并选择共享、隔离或不使用仓库的夹具方式。内容还包括如何为共享仓库中的资源命名和管理状态,以避免测试互相干扰;如何记录创建的资源并在结束时清理;以及如何控制 API 请求量。对于异步注册的工作流等资源,应等待条件满足,而不是固定等待一段时间。修改测试后,先集中运行相关测试进行验证。

适用场景

修改 GitHub CLI 功能或验收测试脚本时,可以参考此技能。它适用于多个测试共用仓库或 API 限额的开发环境,帮助在检查功能行为时减少测试冲突和不必要的资源创建。

使用示例

  • “请为这个功能的验收测试选择合适的仓库夹具方式。”
  • “请修改这个工作流测试,让它检查条件后再继续。”
  • “请检查我修改的测试脚本中的元数据。”

注意事项

实时测试会操作 GitHub 上的资源,并且需要验收测试凭据。验证方法和凭据变量请查阅 acceptance/README.md。

本介绍由 AI(OpenAI Codex)根据公开的 SKILL.md 撰写。准确的规格请查看下方原文。

文档检查

AI 根据 SKILL.md 的内容检查了需要注意的操作和使用前提。评分只依据实际运行的结果(实测对比)。

安全性发送数据、删除文件、执行命令等是否有说明
B部分不足实时测试会创建和删除仓库,文档要求登记延迟清理。
安装难易度所需工具和 API 密钥是否少且有说明
B部分不足需要 Go 测试和 GitHub 凭据,变量见 README。

不计入评分。 由 AI(OpenAI Codex)于 2026年10月26日 评估。仅供参考,安装前请同时查看原文。

如果您认为评估有误,请申请复核

请写明哪一项有误以及原因。无需登录。我们会对照 SKILL.md 重新评估,并在此处更新结果。

此表单受 reCAPTCHA 保护,适用 Google 的隐私权政策和服务条款。

包含的文件(1)

  • SKILL.md7.0 KB

SKILL.md(原文)

安装前可以查看交给 AI 代理的指令内容。

Writing Acceptance Tests

Acceptance tests exercise gh against live GitHub resources. Minimize repository creation and cloning without allowing concurrent scripts to interfere.

Read acceptance/README.md and nearby scripts before editing.

Declare token capability

Every .txtar script must start with exactly one capability declaration:

# requires-user-capability: false

Set the declaration to true only when the script requires a user principal, such as account SSH/GPG keys, personal-account forks, or user membership APIs. Repository and organization operations supported by an installation token should use false.

Choose one repository mode

Every script must contain exactly one declaration:

ModeUse when
fixture-repo shared REPOOne initialized private repository is enough and every operation can coexist with concurrent and accumulated state.
fixture-repo isolated REPOOne initialized private repository is enough, but the test needs clean state, changes repository-global state, or performs multiple coordinated Git ref updates.
fixture-repo noneNo repository is needed, or the test needs multiple repositories, public visibility, special creation options, or repository lifecycle coverage.

Managed fixtures are initialized, have discussions enabled, and are deleted by the harness. Scripts using shared or isolated must not run gh repo create.

With none, create every required repository explicitly and immediately register deferred cleanup. Use defer gh repo delete --yes $ORG/$REPO when the repository should still exist under that name. Use defer cleanup-repo $REPO when testing deletion or renaming; it is scoped to $ORG and treats an already absent repository as success.

Repositories created with an initial commit can remain busy after gh repo create returns. Before renaming one, use wait-for-repository-ready $ORG/$REPO to wait for its default-branch commit. GitHub can retain the repository creation lock after that commit becomes readable, so keep the gh repo rename command inline and allow a 10-second stabilization delay between this readiness check and that command.

Shared fixture contract

Scripts within a group run concurrently. A shared script must remain correct when the repository already contains unrelated resources.

  • Never rename, transfer, archive, delete, or globally reconfigure the repository. Do not toggle features, change its description, or mutate its default branch.
  • Give resources unique, reasonably short names using $RANDOM_STRING, adding $SCRIPT_NAME only when useful. Width-constrained commands such as gh pr status truncate long titles.
  • Make commits unique across concurrent scripts. Unique branch names do not affect commit IDs, so include the script's $RANDOM_STRING in the commit contents or message when scripts could otherwise create the same tree from the same parent.
  • Consolidate related repository-scoped operations, such as merging pull requests, into one isolated script. Unique refs do not prevent concurrent Git pushes and merges in a shared repository from contending.
  • GitHub normalizes some identifiers. Use env2upper for Actions variables and secrets whose generated names are asserted later.
  • Capture the created resource's URL or ID. Filter and paginate list operations; never select the first, latest, or only result.
  • Target the fixture with --repo $ORG/$REPO or GH_REPO=$ORG/$REPO. Clone only when local Git behavior is part of the test.

If any operation violates this contract, use isolated; do not weaken assertions to make sharing appear safe.

API request budgets

Scripts share token-wide API rate limits. Count requests across the whole test process and combine compatible live assertions. Keep coverage for a narrowly limited endpoint in one script so concurrent scripts cannot burst the limit. For Code Search's 10 requests/minute bucket, use at most five HTTP requests in the entire acceptance process, even when they run sequentially. This reserves half the bucket for pagination, retries, and other token activity. Count the requests made by each command, keep representative live coverage, and move remaining variants to unit tests.

Use bounded condition-based waits for asynchronously registered resources. Fixed sleeps are both slower when registration is fast and unreliable when it is slow. Use wait-for-workflow after pushing a new workflow definition, then use wait-for-run before watching or inspecting a triggered workflow run. After gh workflow run, wait-for-run captures the returned run URL when the server provides one and falls back to polling for older servers. On timeout, wait-for-run captures the pushed commit and remote ref, workflow files, recent unfiltered runs, commit check suites, and an Actions API request ID. Use that evidence to distinguish event ingestion, run indexing, filtering, and push/setup failures before changing fixture isolation or timeout budgets. Cancellation tests must use a self-contained workflow with a deliberately long step so the run cannot finish before the cancellation request, plus a short job timeout so a failed cancellation cannot run for the full step. After registration, use wait-for-run-status RUN_ID in_progress before cancellation because the cancellation endpoint can reject a run that is still starting. Do not wait for GitHub to finish cancellation after the command confirms that the request was submitted; that tests Actions' eventual behavior rather than the CLI contract. Do not lengthen registration sleeps to compensate for a short or externally dependent job.

Organization safety

Every live mutation must resolve through $ORG/$REPO, a resource ID or URL captured from something created under $ORG, or fixture cleanup scoped to GH_ACCEPTANCE_ORG. Do not rely on ambient Git remotes or repository context.

Example

env2upper VAR_NAME=TESTSCRIPTS_${RANDOM_STRING}
fixture-repo shared REPO
env GH_REPO=$ORG/$REPO

exec gh variable set $VAR_NAME --body value
exec gh variable get $VAR_NAME
stdout '^value$'

Validate

Run metadata checks without live credentials:

go test -tags=acceptance \
  -run '^(TestSelectAcceptanceTestGroups|TestFilterAcceptanceScripts|TestTokenHasUserCapability|TestAcceptanceScriptsDeclareUserCapabilityRequirement|TestAcceptanceScriptsDeclareFixtureRepository|TestRequiresUserCapabilityForScript|TestValidateFixtureRepositoryDeclaration|TestFixtureRepositoryManager)$' \
  ./acceptance

Run a changed live script with GH_ACCEPTANCE_GROUP and GH_ACCEPTANCE_SCRIPT; see acceptance/README.md for the credential variables. Use -count=1 to bypass the Go test cache. Start with one script. If concurrency is required to reproduce the behavior, pass only the contending scripts as a comma-separated filter and repeat that focused set before widening the run.

评价

还没有评价。欢迎分享你的使用感受。

评论

无需登录即可发表。欢迎分享使用感受、提问,或说明在哪些环境下无法运行。

还没有评论。来写第一条吧。

提交后会立即公开。请勿填写邮箱、电话等个人信息。URL 最多 2 个。

0 / 1000 字

此表单受 reCAPTCHA 保护,适用 Google 的隐私权政策和服务条款。

同一仓库的技能

agentic-workflows

免费有简介

此技能识别 GitHub Agentic Workflows 相关请求的类型,并引导代理读取对应提示或技能文件,涵盖设计、创建、配置、更新、调试和升级。

  • 设计或创建新工作流
  • 更新现有工作流
  • 调查工作流错误
cli/cli4.7万2026年10月25日 更新

Exercise a real command-line program with specified cases or a stated goal, then capture and verify the observed behavior. It produces local media evidence such as a session video, helping reviewers see what the command did without treating the recording as proof of general correctness.

中文简介正在准备中。当前显示英语简介。

  • Record specified CLI test cases
  • Demonstrate a command’s behavior
  • Validate an interactive terminal workflow
cli/cli4.7万2026年10月25日 更新

cli-exercise-evidence

免费有简介

将命令行练习的预期与记录证据逐项核对,按需渲染并检查媒体,返回各案例结果和本地成果文件路径;默认不发布证据。

  • 核验命令行练习的预期
  • 从录制内容生成视频证据
  • 检查视频或屏幕内容
cli/cli4.7万2026年10月25日 更新

cli-exercise-exact

免费有简介

此技能按原样执行指定的命令行测试,保留命令、输入、顺序和预期条件;逐项准备、操作并验证,再依据实际证据标记通过、失败、受阻或仅作观察。

  • 按原样执行命令行测试
  • 保留输入值和案例顺序
  • 对照预期与实际输出
cli/cli4.7万2026年10月25日 更新

cli-exercise-explore

免费有简介

此技能根据目标和已批准的范围选择可观察的命令行检查,逐项完成准备、操作和即时验证,并整理证据、尚未达到的行为及检查结果。

  • 按目标检查命令行操作
  • 明确上传完成的判断条件
  • 逐项准备并验证操作
cli/cli4.7万2026年10月25日 更新

cli-exercise-preflight

免费有简介

这是供 `cli-exercise` 内部使用的准备检查模块,用于核验构建、终端和媒体工具是否可用;缺少依赖时先征得安装同意,安装后重新检查。

  • 录制前检查所需工具
  • 检查视频或 GIF 输出能力
  • 查看缺失依赖的安装步骤
cli/cli4.7万2026年10月25日 更新

查看 cli 的全部技能

报告此技能的问题