十年匠心定制 · 商业建站与技术教学双线并行 咨询热线:400-886-1026 service@lmnt.cn
ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

TiDB 集成测试录制工作流:tests/integrationtest 的 .test/.result 最小化录制实践

TiDB 集成测试录制工作流:tests/integrationtest 的 .test/.result 最小化录制实践 TiDB 集成测试录制工作流tests/integrationtest 的 .test/.result 最小化录制实践【免费下载链接】tidbTiDB is built for agentic workloads that grow unpredictably, with ACID guarantees and native support for transactions, analytics, and vector search. No data silos. No noisy neighbors. No infrastructure ceiling.项目地址: https://gitcode.com/GitHub_Trending/ti/tidb本文围绕 TiDB 仓库中 Agent 技能文档 .agents/skills/tidb-integrationtest-recorder/SKILL.md 展开讲清tests/integrationtest集成测试套件的“录制record- 复核review- 最小化 diff”完整工作流如何从t/目录下的用例路径推导TestName、如何用./run-tests.sh -r精准再生.result文件、以及为什么必须避免无关 result churn。读完你可以独立完成 TiDB 集成测试的录制、校验与结果文件治理理解底层 mysql-tester 的启用/禁用新 collation 双跑机制与数据竞争检查逻辑。技能定位与适用场景该技能文档以 Agent 技能skill的形式定义了一套操作规范其核心声明如下适用场景当修改位于tests/integrationtest/t/**下的集成测试用例或需要为 SQL 行为补充集成测试覆盖时使用本工作流。明确禁忌对该套件不要使用 Go 测试的-record标志-record仅属于那些显式支持的测试套件这一点在 docs/agents/testing-flow.md 的单元测试一节中被再次强调Use -record only for test suites that explicitly support it.。权威出处规范命令细节不写在技能文件里而是统一指向 docs/agents/testing-flow.md 中的Integration tests (/tests/integrationtest)小节。技能文件只保留“指路 流程约束”长命令块集中维护在 playbook 中避免命令细节在多处重复后产生漂移——这一设计原则在 docs/agents/testing-flow.md 开头即有说明“skills under.agents/skills/should point here rather than duplicating long command blocks”。该技能也是仓库级技能清单中的一员.agents/skills/README.md 将其列为九个运维工作流技能之一tidb-integrationtest-recorder: run and review tests/integrationtest recording flow与tidb-verify-profile、tidb-failpoint-test-runner、tidb-realtikv-runner等技能共同构成 TiDB 的 Agent 测试纪律体系。集成测试套件的目录结构理解录制工作流之前先明确tests/integrationtest的布局来源tests/integrationtest/README.md 的 “How It Works” 一节与 tests/integrationtest/run-tests.sh 脚本默认值路径角色tests/integrationtest/t/测试输入.test文件定义 SQL 用例可含##行内注释说明如 t/planner/core/binary_plan.test 中为每段 base64 输入附带的注释tests/integrationtest/r/期望结果与.test同路径的.result文件执行后与之逐字比对tests/integrationtest/s/由 s.zip 解压得到统计信息s/*.json在测试运行前装载保证 planner 相关结果稳定可复现tests/integrationtest/config.toml默认服务端配置开启新 collation、table lock、新字符集等tests/integrationtest/disable_new_collation.toml禁用新 collation 时的替代配置从 run-tests.sh 的默认变量可确认脚本行为statss、mysql_tester_log./integration-test.out脚本在每次运行时通过unzip -qq s.zip重新解压统计目录保证统计基线一致。run-tests.sh还导出了TZAsia/Shanghai注释写明 “make tests stable time zone wise”即结果比对对时区敏感的用例依赖这一固定时区本地调试环境应保持默认。TestName 推导规则技能工作流的第 2 步给出了录制命令的关键输入DeriveTestNamefrom the path undertests/integrationtest/t/without the.testsuffix (example:planner/core/binary_plan).docs/agents/testing-flow.md 中给出了完全一致的映射示例Mapping example: if you modifyt/planner/core/binary_plan.test, thenTestNameisplanner/core/binary_plan.也就是说TestName就是.test文件相对t/的目录路径保留子目录层级、去掉扩展名目录结构在t/与r/之间一一对应。仓库中可以直接验证这一点输入文件 tests/integrationtest/t/planner/core/binary_plan.test 与期望结果文件tests/integrationtest/r/planner/core/binary_plan.result位于镜像路径上。用例的粒度决定了录制的粒度例如t/顶层散布着explain.test、index_merge.test、cte.test等单文件用例而t/planner/core/、t/executor/、t/ddl/等子目录承载成套用例。录制时只指定受影响的TestName这正是下一节“定向录制”要求的直接原因。录制命令定向记录受影响的套件docs/agents/testing-flow.md 的Integration tests小节是权威命令出处pushd tests/integrationtest ./run-tests.sh -r TestName popd结合 tests/integrationtest/README.md 的 Script Options 与 run-tests.sh 的getopts解析逻辑完整参数语义如下-r test-name|all运行t/test-name.test并将执行结果录制回r/test-name.result。指定all表示运行全部用例并整体重录——这正是技能 Guardrails 中“Prefer targeted recording of the affected suite only”要防止的做法除非刻意做全量刷新否则不要使用。-t test-name仅运行不录制提供-r时该选项被忽略脚本中record_case分支优先于$tests分支。回归验证时应使用-t。-d y|Y|n|N|b|B控制测试期间新 collation 的启用状态。默认bcollation_opt2以collation为前缀的用例在启用/禁用两种状态下各跑一遍因此r/下会出现collation_agg_func_enabled.result/collation_agg_func_disabled.result这类成对文件其他用例仅以启用状态运行。y仅启用、n仅禁用。-s tidb-server-path使用已有 tidb-server 二进制跳过构建。-b y|Y|n|N是否构建测试二进制默认构建提供-s时自动跳过。-P port连接已在指定端口运行的 tidb-server跳过本地构建与启停。脚本在执行录制时的实际行为见 run-tests.sh 的run_mysql_tester函数extract_stats解压s.zip得到统计基线start_tidb_server启动服务——默认走unistore-store unistore -path 只有设置了TIDB_TEST_STORE_NAMEtikv环境变量且提供TIKV_PATH时才走-store tikv -path ...-d为禁用模式时改用disable_new_collation.toml配置调用外部工具mysql_tester脚本用go install github.com/pingcap/mysql-tester/srcf2d90ea9522d30c9a8e8d70cc31c7f016ca2801f安装固定版本录制模式即追加--record case参数并始终带--check-errortrue与--collation-disabletrue|false结束后kill -15等待服务退出并在 unistore 场景下check_data_racegrep 服务日志中的DATA RACE命中则整轮测试判失败并打印日志。技能工作流的第 1 步与 AGENTS.md 的 Validation Matrix 相互印证tests/integrationtest/t/**发生变更时的最小验证动作正是 “Record and verify regenerated result correctness (seedocs/agents/testing-flow.md-Integration tests)”。结果文件复核把 diff 压到最小技能工作流的第 3 步是“Review changed files intests/integrationtest/r/**and keep result diffs minimal”配合 docs/agents/testing-flow.md 的补充说明Review changed files intests/integrationtest/rand confirm each diff matches expected behavior. Result files usually do not need manual edits; if edits are necessary, keep them minimal and verify correctness before reporting.落地成可操作清单录制完成后用git diff tests/integrationtest/r/审视全部被重写的结果文件逐行确认每一处变化都能对应到你本次改动应当引起的行为差异计划节点、类型推断、报错文案等。任何无法解释的变化都说明录制范围过大或环境不一致例如统计信息、时区、collation 状态变化结果文件通常不需要人工编辑。README 指出.result是从执行结果“再生”出来的To generate new .result and .json files from execution, use the -r parameter若确需手工修正某一行修改必须最小化并再跑一次用-t TestName只跑不录制的验证模式确认通过后才可报告。技能 Guardrails 的三条规则与上述流程一一对应Prefer targeted recording of the affected suite only只录受影响的TestName避免-r all把无关用例一并重写Avoid unrelated result churnr/下数百个结果文件之间是“零漂移”基线一次 PR 只应触碰与改动相关的文件If result files need manual edits, keep them minimal and verify with another run手工编辑后必须二次验证。进阶next-gen 运行器与真实 TiKV 集群tests/integrationtest/README.md 还记录了第二套运行入口./run-tests-next-gen.sh [run-tests.sh options]它“sets up a real cluster environment and then invokesrun-tests.shwith your provided options”。从 tests/integrationtest/run-tests-next-gen.sh 源码可见其机制设置TIDB_TEST_STORE_NAMEtikv与TIKV_PATH127.0.0.1:2379后委托tests/realtikvtest/scripts/next-gen/bootstrap-test-with-cluster.sh ./run-tests.sh $启动一个本地 3 PD 3 TiKV 1 TiKV-worker MinIO 的 next-gen 集群脚本头部注释列出了所需 TCP 端口pd 2379/2380/2381/2383/2384、tikv 20160-20162/20180-20182、tikv-worker 19000随后以NEXT_GEN1调用run-tests.sh。NEXT_GEN环境变量在 run-tests.sh 的start_tidb_server中会被追加-keyspace-name SYSTEM --tidb-service-scope dxf_service启动参数。因此录制/复核流程本身不变只是后端从 unistore 换成了真实 TiKV同样用-r TestName定向录制同样要复核r/下最小 diff但要注意 next-gen 集群占用固定端口且 docs/agents/testing-flow.md 的 RealTiKV 一节对真实集群的启动/清理纪律启动、探活、测试、强制清理、端口不可达检查仍应遵守。回归验证与日常开发流程技能文档聚焦“录制”而录制的目的始终是让回归验证可信。tests/integrationtest/README.md 的 Typical Workflows 给出日常路径代码变更后的回归make dev或make integrationtest构建并跑全量集成测试用于发现计划变化新增/更新用例在t/添加.test文件或向既有文件追加查询→./run-tests.sh -r casename生成期望结果 → 提交t/与r/两侧改动。与本文主题直接相关的收尾纪律来自 docs/agents/testing-flow.md 的 “Related guidance” 一节准备 PR 更新时要把精确的测试命令写进 PR 描述Tests段并遵循 AGENTS.md 的 Quick Decision Matrix 做回归政策判断。小结TiDB 集成测试录制工作流可以浓缩为四步推导TestNamet/相对路径去.test→./run-tests.sh -r TestName定向录制 → 复核r/下的 diff 是否每处变化都有预期行为解释 → 若手工编辑过结果文件则用只跑不录的模式二次验证。该流程的价值在于把“结果文件再生”约束在最小范围使tests/integrationtest/r/这一庞大回归基线始终保持干净、可审计而底层脚本固定时区、固定统计基线s.zip、collation 双跑与数据竞争检查共同保证了录制结果的确定性。技能文件刻意保持简短、把命令细节集中于 docs/agents/testing-flow.md是 TiDB 面向 Agent 协作的文档分层AGENTS.md 管策略、testing-flow.md 管命令、skills 管流程约束的一个典型样本。【免费下载链接】tidbTiDB is built for agentic workloads that grow unpredictably, with ACID guarantees and native support for transactions, analytics, and vector search. No data silos. No noisy neighbors. No infrastructure ceiling.项目地址: https://gitcode.com/GitHub_Trending/ti/tidb创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表