当断言逻辑需要使用被测代码本身时，应当如何正确开展代码测试？

数据老陈

2026-9-25

原问题翻译

我现在正陷入内心的两个自我的拉扯：一面是追求完美的开发者，另一面是推崇敏捷高效的工程师。

我有一个 Azure Function 会使用 Open XML SDK 实现基础功能，比如向 Word 文档中添加批注。

为了简化调用，我把所有 Open XML SDK 相关代码封装模块化，做成了独立的内部API，可以直接调用如下方法：

WordDocuments.AddComment(documentStream, "I'm looking for this text", "Author", "This is my comment");

目前项目大部分模块都有完备的测试覆盖，从内部函数级别的单元测试，到 Azure Function 端点部署后的端到端集成测试均已覆盖。

但现在我遇到了一个两难的问题。

一套很容易想到的测试步骤是：

传入一个文档（通过 Memory Stream）
调用 AddComment 方法
断言更新后的流中已成功添加了对应批注

测试代码示例：

// ARRANGE
var fileName = $@"{Directory.GetCurrentDirectory()}\Documents\Word.docx";
var bytes = File.ReadAllBytes(fileName);
using (var stream = new MemoryStream())
{
    stream.Write(bytes, 0, bytes.Length);

    // ACT
    WordDocuments.AddComment(stream,
        "the text we are looking for",
        "Martin Hatch", // author of the comment
        "MH", // initials for the author
        "the comment text");
}

// ASSERT
Assert.IsTrue(WordDocuments.GetComments(stream).Any(c => c.Author == "Martin Hatch" && c.Text == "the comment text"));

但这让我陷入了困境：我没法不依赖 Open XML SDK 本身就能断言批注已成功添加。
现在的问题是，既然我已经把所有相关逻辑都封装到了 WordDocuments API 类中，再单独写一套 Open XML SDK 相关的断言代码显得毫无意义。
但如果直接调用我自己封装的 API 来断言同一个 API 的执行结果，这样的做法合理吗？
这看起来像是陷入了自证的逻辑闭环，属于测试失效的情况。

因此我想询问的核心问题是：

当断言逻辑需要用到被测代码本身时，你会怎么测试？

编辑说明：我已更新了问题标题使其表意更准确
原标题："如何测试基于 Open XML SDK 编写的代码？"

解决方案

1. 拆分测试层级，先验证断言方法可信

你当前的测试逻辑本质是同时测试AddComment和GetComments两个关联方法，不属于自证闭环，而是合理的关联功能集成测试。只需要调整测试顺序就能解决逻辑问题：

第一步先单独验证GetComments的正确性：准备一个手动确认过包含固定批注的标准Word文档作为测试物料，直接调用GetComments读取内容，和已知的批注信息做比对，只要这一步测试通过，就可以确认GetComments是可信的断言工具。
第二步再用已经验证过的GetComments去测试AddComment，此时的断言逻辑完全不存在闭环问题。

2. 补充单元测试覆盖封装逻辑

如果追求更高的测试严谨性，可以给WordDocuments类的内部实现补充单元测试，不需要依赖Open XML SDK的实际读写能力：

把Open XML SDK的操作封装成可注入的依赖，用Mock框架模拟SDK的调用过程，验证AddComment执行时确实调用了正确的SDK方法、传入了预期的参数，GetComments执行时确实正确解析了SDK返回的结构。
这类测试可以覆盖你封装逻辑里的各类边界场景，比如传入不存在的匹配文本、空作者名、超长批注内容等异常情况的处理逻辑，不需要实际操作Word文档就能快速执行。

3. 用黄金主版本测试做兜底

如果不想拆分测试，还有更简单的方案：提前准备两份测试物料，一份是未添加批注的原始文档，一份是手动确认过批注正确的标准结果文档（作为黄金基准）。测试时只需要把调用AddComment后的输出流和标准结果文档的二进制内容做对比，完全一致就通过，不需要依赖任何你自己封装的API做断言，直接从二进制层面验证结果正确。

三种方案可以根据项目需求搭配使用：单元测试覆盖边界逻辑，集成测试验证实际功能符合预期，黄金主版本测试做兜底，完全可以解决你担心的自证闭环问题。

内容的提问来源于stack exchange，提问作者Martin Hatch