当断言需要与您正在测试的完全相同的代码时，您如何测试代码？答案

【问题标题】：How do you test code, when the assertion requires the exact same code that you are testing?当断言需要与您正在测试的完全相同的代码时，您如何测试代码？
【发布时间】：2021-11-18 13:18:39
【问题描述】：

因此，我面临着完美主义者与敏捷效率工程师之间的对峙。

我有一个 Azure 函数，它将使用 Open XML SDK 来执行一些基本功能 - 例如，它将 cmets 添加到 Word 文档中。

为简单起见，我将所有 Open XML SDK 代码打包并模块化为一个单独的内部 API，以便我可以调用如下方法：

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

到目前为止，我在项目的大部分内容中都有广泛的单元测试覆盖范围，从单个内部功能级单元测试到 Azure Function 端点的部署后端到端集成测试。

但是，面对这个特殊的问题，我有点进退两难。

一组明显的测试步骤可能是：

提交文档（通过内存流）
调用“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 本身，我无法“断言”已添加评论。

现在 - 编写一大堆单独的 Open XML SDK 代码似乎完全没有意义，因为我已经将它们全部包装在我的“WordDocuments”API 类中。

但是 - 我应该使用自己的 API 来断言使用相同 API 的操作吗？

这感觉有点像内部循环/测试失败。

所以我想真正的问题是：

当断言需要您正在测试的完全相同的代码时，您如何测试代码？

编辑 - 我现在实际上已经更新了主标题，因为我觉得它更有意义

原标题：“您将如何使用 Open XML SDK 测试代码？”

【问题讨论】：

标签： unit-testing openxml-sdk microsoft-unit-testing

【解决方案1】：

好吧，这花了我一点时间，但我想我已经找到了一个我很满意的答案（尽管仍然有一点测试气味）

如果您有其他选择，请随时加入，越多越好！

这就是我所做的。

第 1 步 - 我创建了一堆预先确定的 Word 文档。

没有任何 cmets 的文档
带有一条评论的文档
包含三个 cmets 的文档

然后我创建了单元测试以从文档中检索 cmets，并确认我们拥有正确数量的 cmets。

这有效地证明了“GetComments()”方法工作正常

第 2 步 - 创建单元测试，将一个或多个 cmets 添加到那些源“预先确定的”word 文档文件中。

然后我们可以使用 GetComments()（我们已经证明它按预期工作）来确认我们尝试添加的评论是否有效。

最后一步当然是详细说明所有变体（尝试添加缺少参数的 cmets、提供非 Word 文档等），以提供更全面的代码覆盖率。

总结

我想这里的要点是每个单元测试不必须是孤立地证明的。提供这种总体信心的是测试的集合。

使用我的 API 的一部分来测试我的 API 的另一部分是完全可以的，只要所有部分都包含在它们自己的单独测试中，以便可以正确识别故障 - 没有太多的误报..或更糟.. 误报！

【讨论】：