【免费下载链接】App-Store-Connect-CLIFast, scriptable CLI for the App Store Connect API. Automate TestFlight, builds, submissions, signing, analytics, screenshots, subscriptions, and more项目地址https://gitcode.com/gh_mirrors/ap/App-Store-Connect-CLI点击查看免费下载导读本文是 App-Store-Connect-CLI 仓库中 .agents/skills/develop-asc-change/references/test-matrix.md 的深度展开。它面向任何在 ASC CLI 上新增或修改命令、flag、API 端点、输出格式、退出码或共享 CLI 行为的开发者系统性地定义了一组可复用的测试矩阵从 flag 解析、输出与退出行为、HTTP 与 API 交互到鉴权与进程隔离、真实环境验证。读完本文你将掌握如何用 RED-GREEN 流程为行为变更建立覆盖知道每类变更分别该在哪些层级单元、HTTP、黑盒、live补测试以及如何在保证信号强度的同时避免重复造轮子。测试矩阵在开发流程中的位置test-matrix.md 是 .agents/skills/develop-asc-change/SKILL.md 定义的变更开发流程的核心参考文件之一。该 Skill 将一次 ASC CLI 行为变更组织为写设计说明design note→ 建立 RED先写失败测试→ 校验 API 支持 → 窄范围实现 → 到达 GREEN 并验证 → 交接。其中建立 RED一步明确要求阅读本矩阵按其中列出的 CLI、输出、产物与鉴权用例逐项补测Read references/test-matrix.md for applicable CLI, output, artifact, and auth cases. Reuse sufficient existing coverage; do not duplicate shared parser or renderer tests for every command.矩阵开篇的指导原则值得先牢记Apply the cases relevant to the changed behavior, using existing coverage when it proves the contract. Add tests for distinct observable behavior or demonstrated regressions; shared parser and renderer coverage need not be repeated for each command.即按变更行为选取相关用例能证明契约的既有覆盖直接复用只为可观察的新行为或已证实的回归补测共享的解析器/渲染器覆盖不必在每个命令上重复。这与 docs/TESTING.md 中的总原则一致——Prefer a small number of high-signal tests over broad repetitive matrices宁要少量高信号测试不要大而全的重复矩阵。Flags and parsingflag 与解析的测试要求矩阵对 flag 与解析变更提出四条硬性要求每个新增或变更的 flag 至少补一个有效路径测试valid-path test证明该 flag 在正常使用时确实生效。至少补一个无效值测试断言 stderr 内容与退出码2。退出码 2 即ExitUsageInvalid usage / flags / command invocation定义见 cmd/exit_codes.go。当解析或 dispatch 逻辑变更时覆盖受影响的 flag 排序以及值长得像子命令名的情况——例如--profile builds completion这种 flag 值与子命令名冲突的输入绝不能因解析顺序变化而被错误路由。必需 flag 缺失的错误必须在 stderr 上断言不能只测flag.ErrHelp同时绝不接受并静默忽略任何不支持的 flag 或值。仓库中这两类要求的落地案例非常直观无效布尔值测试cmd/exit_codes_test.go 中的TestBuildsExpiredFlagsInvalidBooleanExitCode对--exclude-expiredmaybe等非法布尔输入断言退出码为ExitUsage2、stderr 包含invalid boolean value且点名了出错的具体 flag。必需 flag 缺失cmd/exit_codes_test.go 的TestBuildsListMissingAppExitCode断言builds list --version 1.2.3缺少--app时退出码为 2且 stderr 必须包含--app is required。flag 值像子命令名cmd/exit_codes_test.go 的getCommandName表驱动用例{flag value matches subcommand name, []string{--profile, builds, completion}, asc completion}以及TestJUnitReportEndToEnd中--profile builds completion --shell bash的完整黑盒验证都专门覆盖了flag 值恰好等于子命令名这一边界。解析归一化cmd/boolean_args_test.go 的TestNormalizeSpacedBooleanFlags用一张 11 行的表驱动矩阵验证normalizeSpacedBooleanFlags覆盖显式 false 置于另一 flag 前、flag 终止符--之后不再归一化、非布尔字符串值原样保留等情形正是矩阵要求的解析变更时覆盖 flag 排序的仓库级佐证。Output and exit behavior输出流、产物与退出码的验证矩阵要求输出相关测试做到结构级断言而不是弱断言解析 JSON 或 XML 并断言字段而不是只做子串匹配strings.Contains。docs/TESTING.md 同样强调For JSON assertions, unmarshal and assert fields (notstrings.Contains)。断言代表性表格或 Markdown 输出的结构与表头而非只检查值存在。对应渲染器测试模式见 docs/TESTING.md 的 For user-facing renderers, assert output structure or headers in addition to value presence。对变更的 CLI 行为用构建出的二进制验证 stdout、stderr 与退出码三者。仓库通过buildASCBlackboxBinarycmd/blackbox_test.go用go build产出真实二进制后以exec.Command运行并分别捕获 stdout/stderr。测试成功与失败两种写入路径既要有成功写出 artifact/报告如 JUnit 报告的用例也要有写入失败目录不可写、路径不存在的用例。防止重复 usage 输出或重复错误输出——一次失败只应该打印一份诊断。仓库中的黑盒用例完整示范了构建二进制 精确断言 stdout/stderr/退出码的做法cmd/blackbox_test.go 的TestUnknownInputRecoveryWithBuiltBinary对未知命令builds lsit与未知 flag--ap逐字符断言 stderr 的完整文本含Try:/For help:引导行确认退出码为ExitUsage并额外验证私有值不会泄漏进 stderrPRIVATE_VALUE不得出现在错误输出中。cmd/exit_codes_test.go 的TestJUnitReportEndToEnd运行真实二进制生成 JUnit XML再xml.Unmarshal解析并断言testsuite/testcase的name属性是解析结构化产物而非子串匹配的样板。退出码本身是一个稳定的契约面值得单独理解。ExitCodeFromError是退出码判定的唯一事实来源cmd/exit_codes.go其映射规则为退出码含义触发条件0成功无错误1通用/未分类错误兜底2用法错误flag/调用不合法flag.ErrHelp、上报的 usage error、shared.IsReportedUsageError3鉴权失败缺失/未授权/被禁止ErrMissingAuth、ErrUnauthorized、ErrForbidden、Apple 凭据无效4资源不存在ErrNotFound5冲突/资源已存在ErrConflict6只读模式拒绝变更请求readonly.ErrRefused10–59HTTP 4xx10 (status - 400)如 400→10、422→3260–99HTTP 5xx60 (status - 500)如 500→60、502→62、503→63cmd/exit_codes_test.go 的TestExitCodeFromError用 17 个表驱动用例覆盖了这张表包括包裹错误wrapped error、errors.Join组合错误、以及子进程退出码透传shared.NewProcessExitError。矩阵要求用构建的二进制验证退出码正是因为运行时真实发生的错误往往是被多层%w包裹的errors.Is/errors.As语义必须在黑盒层面被验证。HTTP and API behavior用 httptest 验证 API 交互对于 API 面变更矩阵要求用net/http/httptest断言请求的方法、路径、query 参数、请求头与请求体并覆盖三类响应现实的非空响应realistic non-empty response——不能只拿{data:[]}空响应敷衍校验失败validation failureAPI 错误API error。同时在把重复的客户端测试合并为表驱动形式时每个响应族至少保留一个代表性的响应解码断言凡适用处都要覆盖分页与空响应。仓库的 HTTP 测试基建支持这一点cmd/exit_codes_test.go 中的rewriteHostTransport把针对生产 base URL 构造的请求重定向到测试服务器newHTTPStatusTestClient则在t.TempDir()中生成真实的 ECDSA P-256 私钥与 PEM 文件来构造asc.Client让客户端代码完全按真实路径运行。TestExitCodeFromError_RetryExhaustedStatusescmd/exit_codes_test.go用httptest.NewServer持续返回 503/429并借助t.Setenv(ASC_MAX_RETRIES, 1)压缩重试窗口验证重试耗尽后退出码与遥测中的 HTTP 状态都被保留而非塌缩成通用退出码 1。TestExitCodeFromError_AppleNotAuthorizedPayloadcmd/exit_codes_test.go喂入真实形状的 Apple 401 响应code: NOT_AUTHORIZED确认其映射到ExitAuth——这正对应矩阵覆盖 API 错误的要求错误响应也必须用真实负载形状测试而不是随便一个错误码。一个重要的并发陷阱值得留意docs/TESTING.md 的 Assertions Outside the Test Goroutine 一节t.Fatal/t.Fatalf/t.FailNow只能在运行测试的 goroutine 中调用。在httptesthandler 内调用它们会跳过响应写出、让被测客户端永远等待在工作 goroutine 或注入的依赖桩里调用则会提前终止该 goroutine 导致测试死锁。仓库为此提供了 internal/handlertest/handlertest.goAsserter.Errorf以Errorf任何 goroutine 安全记录失败并返回一个可回传给被测代码的错误Asserter.Respond向 handler 写出一个符合 App Store Connect 错误信封格式errors数组、TEST_FIXTURE_ASSERTION码的 HTTP 500 响应Asserter.Response则供必须返回*http.Response的 fixture 构造器使用。这让被测客户端以与真实 API 失败完全相同的方式解码 fixture 失败而不是卡在超时转储里。Auth and process isolation鉴权测试的环境隔离矩阵对鉴权相关测试有严格的进程隔离要求仓库测试一律以ASC_BYPASS_KEYCHAIN1运行避免宿主钥匙串中的 profile 干扰结果。docs/TESTING.md 的 Running Tests 一节给出了标准命令ASC_BYPASS_KEYCHAIN1 make test # 运行全部测试 ASC_BYPASS_KEYCHAIN1 go test -v ./... # 详细输出 ASC_BYPASS_KEYCHAIN1 go test -run TestName ./pkg # 运行指定测试make test目标内部也会设置该变量但手动跑go test时必须自行带上。鉴权敏感测试使用t.Setenv和临时ASC_CONFIG_PATH把配置限制在测试隔离区内。按需在本地设置或清除这些环境变量ASC_PROFILE、ASC_KEY_ID、ASC_ISSUER_ID、ASC_PRIVATE_KEY_PATH、ASC_PRIVATE_KEY、ASC_PRIVATE_KEY_B64、ASC_STRICT_AUTH。它们在仓库的 internal/auth 包中有实际引用如 internal/auth/doctor.go覆盖了profile 选择、API Key 三件套、私钥来源文件路径 vs 内联内容 vs Base64、严格鉴权开关等完整鉴权输入面。无法使用t.Setenv时必须精确恢复进程原状——t.Setenv本身会在测试结束时自动还原环境因此凡是环境变量敏感的测试都应优先使用它只有确实不能用的场景才手动保存/恢复且恢复必须精确。t.Skip只允许用于某个具体、可文档化且可复现的条件绝不允许用宽泛的字符串匹配错误来跳过——跳过条件必须具体到能指出为什么在这里跳过、何时会恢复运行。Live verification真实环境验证的纪律矩阵最后定义了 live真实环境验证的四个纪律优先只读调用read-only calls first——真实 App Store Connect 环境验证先跑只读命令最大限度降低副作用。需要授权变更与清理时使用一次性资源记录其 ID并在结束后删除或取消它——绝不在真实环境里留下垃圾数据。断言外部可见的结果而不只是 HTTP 状态码成功——例如创建资源后要确认其真的出现在列表/详情中而不是 HTTP 200 就算通过。报告任何未能清理的状态——如果某次验证因故残留了资源必须显式报告而不是静默略过。这与 .agents/skills/develop-asc-change/SKILL.md 的 Reach GREEN and verify 步骤呼应live smoke test 仅在行为依赖 App Store Connect 平台特性时才跑最小集且Prefer read-only calls; live mutations and cleanup require authority underAGENTS.md——即 live 变更与清理都需要按 AGENTS.md 获得授权。把矩阵落进一次变更RED-GREEN 工作流将上述五块矩阵与 RED-GREEN 流程结合一次 ASC CLI 行为变更的测试推进路径可以归纳为写失败测试REDbug 先最小复现新功能从 CLI 级契约测试起步行为性重构先补齐缺失的特征覆盖characterization coverage。按矩阵选相关用例新 flag 加有效路径 无效值stderr 退出码 2新端点加httptest断言方法/路径/query/header/body 非空响应 校验失败 API 错误渲染变更加结构/表头断言。实现GREEN窄范围实现用法错误返回退出码 2见 .agents/skills/develop-asc-change/SKILL.md 的 Implement narrowly每次小修后重跑聚焦失败测试。验证跑相邻包与命令测试用真实二进制验证调用、输出流与退出码注意不要与并发任务共享固定的/tmp/asc路径必要时跑最小 live smoke test只读优先一次性资源、记录 ID、事后清理并报告残留。收尾--help变更时按 AGENTS.md 的验证门禁重新生成命令文档公共行为、共享代码、发布面与实质性缺陷/安全修复需要走完整门禁。全程的取舍原则始终是矩阵开头那句话复用能证明契约的既有覆盖只为新的可观察行为或已证实回归补测。这正是 ASC CLI 在 docs/TESTING.md、cmd 目录数百个测试文件与 internal/asc 大量表驱动 HTTP 测试中贯彻的高信号、低重复测试文化也是本矩阵希望每一位贡献者继承的默认行为。赞分享【免费下载链接】App-Store-Connect-CLIFast, scriptable CLI for the App Store Connect API. Automate TestFlight, builds, submissions, signing, analytics, screenshots, subscriptions, and more项目地址https://gitcode.com/gh_mirrors/ap/App-Store-Connect-CLI点击查看免费下载相关推荐App-Store-Connect-CLI 的 Go 代码规范格式化、错误处理、CLI 行为与测试最佳实践App Store Connect CLI 的 Go 代码规范格式化、错误处理、CLI 行为与测试最佳实践 导读本文基于仓库根目录的 docs/GO_STAVanity 初探Ruby 生态最流行的 A/B 测试框架实验驱动开发为什么值得一试Vanity 初探Ruby 生态最流行的 A/B 测试框架实验驱动开发为什么值得一试 在竞争激烈的 Web 世界里拍脑袋决定按钮该用红色还是蓝色往往Django CMS 扩展测试指南为你的 App 与插件编写高质量单元测试Django CMS 扩展测试指南为你的 App 与插件编写高质量单元测试 Django CMS 的扩展自定义 App 与自定义插件在运行时并不通过传统的CMS后端上一篇React Native In-App Purchases轻松实现应用内购买和订阅下一篇Windows权限提升终极指南NSudo让你轻松获取系统最高权限创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考