让 Windows 测试夹具摆脱编码与 Git 全局配置

一次 Windows 全量测试出现了两组错误，而且都发生在产品断言之前。第一组需要解析子进程返回的 JSON，却拿不到可用的 stdout；第二组刚创建临时 Git 仓库，工作区立即显示已有修改。

应用逻辑没有回归。测试夹具让工作站默认值参与了证据解码和仓库初始化。修复这两个边界后，34 个准备阶段错误消失，原本要验证的业务断言才能正常执行。

两组症状都指向产品代码之外

第一组共有 10 个子进程错误。子命令输出 UTF-8 文本，其中包含非 ASCII 字符。帮助函数使用 text=True 和 capture_output=True，却没有指定编码。受影响的 Windows 主机在捕获路径中解码失败，调用方因而无法取得准备解析的 JSON。

第二组共有 24 个 Git 夹具错误。测试创建共享克隆，并假设起始工作区干净。机器全局 core.autocrlf 在第一次 checkout 时转换了换行，导致测试尚未执行任何动作，工作树内容就已经与索引不同。

两组故障具有同一结构：测试夹具把机器策略当成了隐藏输入。

已完成修复只改动了测试帮助函数和回归用例，没有修改应用流程。本文审稿使用经过脱敏的差异摘要和已完成检查结果作为证据。

控制子进程文本边界

Python 文档说明，传入 text、encoding 或 errors 后，subprocess.run() 会用文本模式处理标准流；只启用文本模式时，解码依赖 io.TextIOWrapper 的默认值。明确传入 encoding 和 errors，可以把转换规则写进调用契约（Python subprocess）。

共享帮助函数从隐式解码改为显式声明：

def run_python(script, *args):
    command = [
        sys.executable,
        str(script),
        *map(str, args),
    ]
    return subprocess.run(
        command,
        text=True,
        encoding="utf-8",
        errors="replace",
        capture_output=True,
        check=False,
    )

每个参数承担独立职责：

• sys.executable 使用与测试进程相同的 Python 解释器；
• encoding="utf-8" 对齐子程序输出契约，不再跟随工作站区域设置；
• errors="replace" 遇到意外字节时仍保留可读诊断；
• capture_output=True 为断言和错误报告保留两个输出流；
• check=False 让夹具自行检查结构化结果和退出码。

errors="replace" 包含明确取舍：诊断记录的连续性优先于字节完全一致。标准输出如果是签名载荷、二进制产物或字节级协议，应捕获 bytes，并在经过单独测试的解析器中严格解码。替换字符不能掩盖已经损坏的机器输出。

断言层还应区分传输故障和产品行为。解析失败时，要报告退出码以及经过脱敏的输出片段。否则，解码器错误很容易被误报成业务规则失败。

在第一次 checkout 前应用 Git 策略

原来的 Git 夹具在克隆结束后才写仓库配置，此时机已经太晚。git clone 在创建仓库的过程中完成 checkout，全局换行规则可能已经改写工作树。

Git 的 clone 命令支持命令级配置。文档说明，-c 提供的值会在仓库初始化后、抓取与 checkout 前写入新仓库（git clone）。因此，夹具把策略移进克隆命令：

git \
  -c core.autocrlf=false \
  clone \
  --shared \
  <source> \
  <fixture>
git \
  -C <fixture> \
  status \
  --short

第二条命令属于夹具契约。一份临时仓库只有先证明基线干净，后续失败才能准确归因于测试动作。缺少这个断言时，测试无法区分自身修改与 checkout 阶段的漂移。

Git 属性文档解释了宿主机为什么会影响结果：路径没有显式 eol 规则时，工作树换行可能由 core.autocrlf 或 core.eol 决定（Git attributes）。

真实源码仓库通常应在 .gitattributes 中保存可审查的长期换行策略。命令级设置在这里承担更窄的职责：测试夹具完全拥有临时克隆，因此要在第一次 checkout 前隔离操作者的全局 Git 配置。

先验证边界，再运行完整套件

修复采用分层验证：

1. 重跑原先丢失可用输出的 10 项子进程测试；
2. 重跑 Git 夹具测试，并要求新克隆的 status --short 为空；
3. 执行完整本地验证入口；
4. 审查精确差异，确认只有测试帮助函数和回归用例发生变化；
5. 精确 PR head 的全部受保护检查通过后才允许合并；
6. 合并后的 main 提交再次通过对应检查。

针对性测试证明两个边界修复已经生效。完整本地门禁随后通过 131 项内容检查和 694 项仓库测试，15 项按设计跳过，没有失败。Pull Request 的 5 项必需检查也在受保护合并前全部成功。

验证顺序可以同时兼顾定位与回归。小范围测试证明直接机制；完整套件用于发现集中帮助函数或夹具初始化方式是否引入了新的假设。

不让宿主机默认值进入测试证据

可重复测试无需模拟所有平台，但会声明所有影响输入、证据和初始状态的平台转换。

对子进程，应记录可执行程序、参数、预期编码、解码策略、环境覆盖、退出码与捕获输出。对 Git 夹具，应记录 checkout 前的配置、属性、初始状态以及测试计划执行的准确修改。

可复用结论是：转换发生前先确定边界策略。字节进入断言前按明确契约解码；仓库第一次 checkout 前先固定夹具策略；随后为初始基线本身增加断言。这样，依赖工作站的准备阶段错误就能转化为稳定、可审查的测试证据。

限制

这套方法无法消除全部 Windows 差异。文件系统大小写、路径长度、程序查找、权限、杀毒软件钩子和 Shell 引号仍可能影响集成测试。只有在套件确实遇到某个变量时，才需要为它补充一项明确边界与一条回归断言。

不能把 errors="replace" 当成通用解析策略。替换字符会改变结构化输出含义时，应明确失败。也不能用 core.autocrlf=false 覆盖真实仓库已经审查的 .gitattributes；夹具级设置只适用于由测试代码控制、且需要稳定起始字节的一次性仓库。