CLIAI 技能【免费下载链接】cliThe official Lark/飞书 CLI tool, maintained by the larksuite team — built for humans and AI Agents. Covers core business domains including Messenger, Docs, Base, Sheets, Calendar, Mail, Tasks, Meetings, and more, with 200 commands and 20 AI Agent Skills.项目地址https://gitcode.com/gh_mirrors/cli414/cli点击查看免费下载本篇指南围绕 lark-cli官方 Lark/飞书 CLI 工具的端到端测试模块tests/cli_e2e展开说明如何从用户视角编译并运行真实二进制、以场景化工作流验证命令行为、并用coverage.md度量领域命令覆盖率。读完本文你将掌握共享测试框架core.go的核心 APIRequest/Result/RunCmd/重试与清理机制、参考用例的编写范式、以及配套cli-e2e-testcase-writer技能的标准化流程可直接上手为任意领域如 docs、im、calendar、task编写可复现的 E2E 测试。模块定位为什么要做 CLI 端到端测试tests/cli_e2e/README.md开宗明义地指出这个目录的职责是从用户视角验证真实的 CLI 工作流——编译出二进制、端到端地执行命令捕捉那些单元测试无法直观暴露的回归问题。它与仓库内其他测试层级如cmd/下的单元测试、tests/plugin_e2e/插件 E2E、tests/sidecar_e2e/侧车 E2E形成互补单元测试验证函数逻辑而 E2E 验证的是「一个真实用户敲下一条命令后进程、参数解析、认证、网络、输出格式整条链路是否按预期工作」。从目录结构看该模块已经按领域组织了大量用例包括application/、apps/、base/、calendar/、config/、contact/、docs/、drive/、dryrun/、event/、im/、mail/、markdown/、minutes/、note/、okr/、sheets/、slides/、task/、vc/、whiteboard/、wiki/等领域目录每个领域目录下除*_test.go用例文件外通常还维护一份coverage.md覆盖率报告可参考 docs 领域示例。模块构成What Is HereREADME 将模块划分为三个核心部分组成路径作用共享 E2E 测试框架tests/cli_e2e/core.go 与 core_test.go封装子进程执行、参数构造、二进制定位、重试、环境注入、断言与清理工具参考用例tests/cli_e2e/demo/展示「最小任务生命周期」工作流的写法作为新领域用例的模板本地技能tests/cli_e2e/cli-e2e-testcase-writer/用于新增或更新本模块用例文件的配套 Agent 技能其中cli-e2e-testcase-writer是一个以SKILL.md为入口的本地技能明确要求「一次只处理一个领域产出恰好两件产物tests/cli_e2e/{domain}/下的工作流用例文件以及该领域的coverage.md」并强调不要改动共享支撑代码core.godemo/目录仅作参考。安装并使用测试用例编写技能README 给出了贡献者新增用例的第一步——先安装并启用本地技能npx skills add ./tests/cli_e2e/cli-e2e-testcase-writer安装后遵循 tests/cli_e2e/cli-e2e-testcase-writer/SKILL.md 工作。技能元数据frontmatter声明其适用场景为编译后的lark-cli的某一个tests/cli_e2e/{domain}领域新增或更新 Go CLI E2E 覆盖尤其是需要实机--help或schema探索、基于场景的clie2e.RunCmd工作流、以及每领域coverage.md维护时。技能元数据还声明了前置依赖bins: [lark-cli]即本地必须有编译好的lark-cli二进制。README 提供的示例提示词可直接作为 AI Agent 的任务描述Use $cli-e2e-testcase-writer to write lark-cli xxx domain related testcases. Put them under tests/cli_e2e/xxx.共享测试框架深度解析core.gotests/cli_e2e/core.go是整个 E2E 模块的地基。它导出常量、跳过守卫、请求/结果类型、命令执行与重试、等待轮询、清理辅助与断言方法下面逐一拆解。二进制定位ResolveBinaryPathResolveBinaryPath按固定优先级寻找lark-cli二进制core.go 对应实现Request.BinaryPath显式指定最高优先级环境变量LARK_CLI_BINEnvBinaryPath常量项目根目录下的./lark-cli通过向上查找名为tests的目录标记来定位项目根系统PATH中的lark-cli。normalizeBinaryPath会校验路径存在、不是目录、且具备可执行权限0o111。core_test.go中TestResolveBinaryPath用临时目录 假二进制覆盖了「请求路径优先」「环境变量生效」「项目根二进制」「拒绝不可执行文件」四条分支core_test.go#L19-L69。Request 结构一次 lark-cli 调用的完整描述Request是测试对「一次命令调用」的声明式描述core.go#L136-L161Args []string必填命令路径与普通 flag不含二进制名Params any可选非空时序列化为--params json对应 URL/路径参数Data any可选非空时序列化为--data json对应请求体Stdin []byte可选成为子进程 stdin传空切片可显式演练空 stdin 行为BinaryPath string可选空值则按上文优先级解析DefaultAs string可选非空时追加--as value如user/botFormat string可选非空时追加--format formatWorkDir string可选设置子进程工作目录Env map[string]string可选仅对本次子进程增改环境变量Yes bool为高危写命令确认。为true时 runner 追加--yes以通过框架级确认门禁对非高危命令设置Yes会报unknown flag: --yes。BuildArgscore.go#L572-L602按固定顺序拼装先Args再--as、--format、--yes最后--params/--data的 JSON。core_test.go的TestBuildArgs验证了 JSON 编码、flag 追加与「Args 必填」约束core_test.go#L71-L101。Result 结构捕获进程执行结果Resultcore.go#L163-L171记录BinaryPath、Args、ExitCode、Stdout、Stderr与RunErr。进程非零退出时RunErr为*exec.ExitErrorexitCode辅助函数提取退出码core.go#L624-L633。结果上还挂载了断言与解析方法AssertExitCode(t, code)断言退出码core.go#L660-L663AssertStdoutStatus(t, expected)统一断言 stdout JSON 状态兼容{ok: ...}shortcut 风格与{code: ...}service 风格两种响应形态core.go#L669-L681StdoutJSON(t)/StderrJSON(t)将对应流按 JSON 解析core.go#L636-L657。这套「同一断言入口兼容两种响应形状」的设计让用例无需在 shortcut 风格{ok}与 service 风格{code}之间分支保持全模块断言统一。RunCmd 与自动重试默认应对瞬时服务错误RunCmdcore.go#L222-L226默认携带重试策略执行当子进程输出中出现结构化服务错误{error:{retryable:true}}时自动以有界指数退避重跑ResultHasRetryableError检查 stdout/stderr 中的error.retryablecore.go#L386-L399。默认参数core.go#L28-L37重试次数4 次初始延迟1 秒最大延迟6 秒退避倍数2。RunCmdWithRetrycore.go#L334-L382暴露完整可配置项Attempts、InitialDelay、MaxDelay、BackoffMultiple、ShouldRetry自定义判断函数并尊重ctx取消。core_test.go用假 CLI 验证了「可重试错误默认重试至成功」「不可重试错误只跑一次」core_test.go#L404-L433假 CLI 脚本中的可重试错误样例为{error:{type:api,code:1061045,message:resource contention occurred, please retry.,retryable:true}}说明这是针对真实 API「资源争用」类瞬时错误的通用兜底。环境与凭证注入buildCommandEnvbuildCommandEnvcore.go#L266-L319在继承当前进程环境的基础上按DefaultAs身份注入共享测试凭证DefaultAs: bot当标准环境缺少LARKSUITE_CLI_APP_ID、LARKSUITE_CLI_APP_SECRET、LARKSUITE_CLI_TENANT_ACCESS_TOKEN时用TEST_BOT1_APP_ID与TEST_TENANT_ACCESS_TOKEN兜底DefaultAs: user类似地用TEST_BOT1_APP_ID与TEST_USER_ACCESS_TOKEN兜底注入LARKSUITE_CLI_USER_ACCESS_TOKEN。同时保证标准环境含 dry-run 夹具与Request.Env显式覆盖优先级永远高于共享TEST_*凭证hasCredentialEnv与逐 key 覆盖逻辑。core_test.go的TestRunCmd子测试对此有充分覆盖core_test.go#L345-L402。跳过守卫SkipWithoutUserToken / SkipWithoutTenantAccessTokenE2E 用例分两类依赖真实用户登录的--as user与依赖租户应用机器人凭证的--as bot。两个跳过守卫在凭证缺失时优雅跳过SkipWithoutUserToken(t)core.go#L39-L76当环境含LARKSUITE_CLI_USER_ACCESS_TOKEN或TEST_USER_ACCESS_TOKEN时直接通过否则调用lark-cli auth status --verify检查本地登录解析 stdout JSON要求identity user且verified为真否则t.Skip并说明原因SkipWithoutTenantAccessToken(t)core.go#L78-L117要求TEST_TENANT_ACCESS_TOKEN或LARKSUITE_CLI_TENANT_ACCESS_TOKEN与TEST_BOT1_APP_ID或LARKSUITE_CLI_APP_ID成对存在缺失时回退到auth status --verify校验本地 bot 配置要求identities.bot.status ready且identities.bot.verified为真。等待、清理与抑制WaitForCondition / CleanupContext / ReportCleanupFailure真实外部 API 的清理如删除刚创建的资源具有最终一致性框架提供成套机制CleanupTimeout60 秒为外层拆除预算CleanupContext()core.go#L449-L451返回有界超时的 teardown context防止远端 API 卡死时清理无限期悬挂WaitForConditioncore.go#L403-L439以TimeoutInterval轮询条件支持TimeoutError自定义超时错误core_test.go的TestWaitForCondition验证了轮询成功与自定义超时错误两条路径core_test.go#L458-L485ReportCleanupFailurecore.go#L454-L475统一输出清理失败信息且CleanupWarning包装的错误只记日志不判失败core.go#L185-L199isCleanupSuppressedResultcore.go#L477-L500对「not found / HTTP 404」以及限流类错误error.type api_error且 code 为800004135或消息含 limited视为可忽略的清理结果——资源已不存在或正被限流不值得把父测试判红。资源命名与 JSON 提取GenerateSuffix()core.go#L442-L445生成高熵 UTC 时间戳后缀20060102-150405 纳秒用于远端资源命名保证并发/重复运行时资源名唯一DryRunGet/DryRunDatacore.go#L119-L134从标准成功信封中读取 dry-run 负载优先data.path缺失时回退到顶层pathextractJSONPayloadcore.go#L502-L526从混合文本输出中稳健提取最后一个 JSON 对象供重试判定与错误解析使用。参考用例拆解demo 中的任务生命周期tests/cli_e2e/demo/task_lifecycle_test.go 是官方提供的「最小参考用例」演示一个完整的 create → update → get 生命周期工作流其写法要点构成了所有领域用例的模板顶层测试 t.Run子步骤TestDemo_TaskLifecycle作为顶层内部用create as bot/update as bot/get as bot三个子测试串成工作流统一超时ctx, cancel : context.WithTimeout(context.Background(), 2*time.Minute)并在t.Cleanup(cancel)释放唯一资源名用 UTC 时间戳构造lark-cli-e2e-create-suffix之类的名称与技能的「中性前缀」护栏一致短路键 持久化断言create 后从 stdout 提取data.guid存入变量供后续步骤使用get 步骤不仅断言退出码还断言data.task.guid、data.task.summary、data.task.description与创建/更新时一致——即「读后写」证明状态真正持久化而不是只看退出码父级清理注册parentT.Cleanup(func(){...})注册删除任务即使中间子测试失败也能兜底清理删除使用clie2e.CleanupContext()限制清理时长并用clie2e.ReportCleanupFailure统一报告写命令确认删除命令显式设置Yes: true因为task tasks delete属高危写命令需要--yes通过确认门禁。请求构造上命令路径与普通 flag 放ArgsURL/路径参数放Params如task tasks get的{task_guid: taskGUID}请求体放Data如task create的{summary: ..., description: ...}身份用DefaultAs: bot。用例编写标准SKILL.md 的六步工作流tests/cli_e2e/cli-e2e-testcase-writer/SKILL.md 为编写用例定义了标准化流程先探索实机 CLI 再写代码依次执行lark-cli --help、lark-cli domain --help、lark-cli domain shortcut -h、lark-cli domain group --help、lark-cli domain group method -h与lark-cli schema domain.group.method确保命令形状与参数结构来自真实输出统计叶命令作为分母叶命令是「执行动作、无子命令」的命令task create计为 1 个叶命令task tasks get也计为 1 个参数组合不计入复用已有领域覆盖不统计demo/写代码前先选定证明面识别可证明的风险非法输入、缺失前置条件、身份/权限、状态迁移、输出形状、清理安全若只有 happy path 可测须在coverage.md中记录被阻塞的风险区域新增或更新工作流用例使用clie2e.RunCmd(ctx, clie2e.Request{...})命令路径与普通 flag 放ArgsJSON 放ParamsURL/路径参数与Data请求体每个工作流一个顶层测试 t.Run子步骤在parentT.Cleanup注册拆除改动已有命令断言前先核实 JSON 响应形状稳定运行并迭代go test ./tests/cli_e2e/{domain} -count1命令形状不清时回到第 1 步的 help/schema 探索刷新领域产物更新用例文件与coverage.md分母从实机 help 输出重算每个命令标记shortcut或api整域一张命令表。核心断言规则shortcut 响应{ok: bool}断言trueAPI 响应{code: int}断言0。只有断言了返回字段或持久化状态而非仅退出码才算「已覆盖」仅在parentT.Cleanup中执行的拆除不算覆盖同一工作流内创建资源的delete除外。维护 coverage.md覆盖率度量每个真实领域目录维护一份coverage.mddemo 参考模板 展示了推荐结构demo 仅为教学模板数字与命令清单是示意性的不代表正式覆盖统计docs 领域 是真实示例其 Metrics 显示 Denominator 12、Covered 9、Coverage 75.0%。推荐结构包含三节Metrics分母N 个叶命令、已覆盖数、覆盖率百分比Summary逐一复述每个Test...工作流及其关键t.Run(...)证明点以及主要阻塞项如「需要真实用户 open_id」「bot-only 环境下不可用」Command Table单张命令表列为Status | Cmd | Type | Testcase | Key parameter shapes | Notes / uncovered reason每个命令标记shortcut或api用例条目写成go test -run友好的形式如task_lifecycle_test.go::TestDemo_TaskLifecycle/create。模板还特别强调分母必须从实机lark-cli --help探索重算不得照抄跳过命令保持未选中并把t.Skip(...)的理由作为「未覆盖原因」。运行方式编译与执行README 给出的运行步骤make build go test ./tests/cli_e2e/... -count1其中make build会通过 Makefile 中的go build -trimpath -ldflags $(LDFLAGS) -o $(BINARY) .在项目根产出lark-cli二进制——这正是ResolveBinaryPath的第三个候选来源。-count1用于禁用 Go 测试缓存确保每次都真跑。运行前按需设置环境变量二进制路径LARK_CLI_BIN用户凭证LARKSUITE_CLI_USER_ACCESS_TOKEN/TEST_USER_ACCESS_TOKEN租户凭证LARKSUITE_CLI_TENANT_ACCESS_TOKEN/TEST_TENANT_ACCESS_TOKEN与TEST_BOT1_APP_ID凭证与本地登录均缺失时依赖真实身份的用例会被跳过守卫优雅跳过而非失败。纵深示例stdin 回归测试如何借力框架stdin_regression_test.go 展示了框架在「无需真实凭证」场景下的用法通过setDryRunConfigEnv只设置LARKSUITE_CLI_APP_ID/LARKSUITE_CLI_APP_SECRET/LARKSUITE_CLI_BRAND即可进入 dry-run 模式。成功用例验证--params -/--data -从 stdin 读取 JSONapi与 service 命令都覆盖并断言 dry-run 信封中的method、url、params/body错误用例则断言退出码 2、stderr 信封ok:false、error.type validation与固定报错文案如--params: stdin is empty (did you forget to pipe input?)与--params and --data cannot both read from stdin (-)。这段用例同时验证了「单引号包裹 JSON 会被剥离」的输入宽容行为是「框架 dry-run 模式 结构化错误信封」三者配合的典型范本。写作与维护护栏速查以 bot 身份运行为主不要假定--as user可用新真实用例不要放进demo/不依赖预先存在的远端数据不伪造open_id、会话、文档等远端夹具优先确定性负例而非租户相关的断言Params/Data字段以 help/schema 为准不臆测远端可见测试数据使用中性前缀如lark-cli-e2e-或domain-e2e-不出现 agent/模型/厂商品牌名一条命令只有在断言了返回字段或持久化状态而非仅退出码时才计入覆盖。综上tests/cli_e2e是一套自洽、可扩展、面向真实用户视角的 E2E 测试体系core.go提供进程级执行、自动重试、凭证注入、清理兜底等基础设施demo与SKILL.md给出标准化用例范式coverage.md提供可量化的领域覆盖视图。对 lark-cli 的贡献者而言遵循「先探索 help/schema、场景化编写、读后写证明、如实记录阻塞项」的流程即可为任意领域持续沉淀高质量端到端回归保障。赞分享CLIAI 技能【免费下载链接】cliThe official Lark/飞书 CLI tool, maintained by the larksuite team — built for humans and AI Agents. Covers core business domains including Messenger, Docs, Base, Sheets, Calendar, Mail, Tasks, Meetings, and more, with 200 commands and 20 AI Agent Skills.项目地址https://gitcode.com/gh_mirrors/cli414/cli点击查看免费下载相关推荐深入 zstd CLI 测试框架基于 run.py 的命令行端到端回归测试实战深入 zstd CLI 测试框架基于 run.py 的命令行端到端回归测试实战 导读 本文围绕 MongoDB 仓库内 vendored 的 zstd 源码数据库文档数据库后端VisionCamera 真机 Harness 测试指南为命令式 API 编写端到端回归测试VisionCamera 真机 Harness 测试指南为命令式 API 编写端到端回归测试 导读 本文介绍 react native vision came移动开发音视频bruno-tests 测试台指南用真实 API Collection 对 Bruno CLI 做端到端验证bruno tests 测试台指南用真实 API Collection 对 Bruno CLI 做端到端验证 bruno tests 是 Bruno 仓库中专开发工具接口测试桌面应用CLI创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考