单元测试通过率/不合格率的确定？

Question

公平地说，几乎所有单元测试框架都使用断言或单个断言来确定测试是否已通过或失败？

尤其是，是否有任何框架可以将测试的文本输出与已知的“黄金”版本进行比较，以确定测试是否通过或失败？

我试图测试的代码是有状态的，这些方法可以有很长的历史。我的想法是，我应该生成记录这个历史的文本输出(可能是几十个状态转换)，并将它与预期的转换进行比较，因此我得到了整个历史的一次传递/失败。

相反，我可以将单个测试分解为20个测试，为每个测试分别设置一个新的状态，然后断言下一个状态与所有20个测试的预期状态相同，但这似乎是毫无意义和浪费的。

编辑

为了澄清-我不是在找工具，也不是推荐。我已经在做我建议的‘手动’，我希望得到一些关于这是否算“单元测试”的洞察力。我不想问这个问题，因为我认为这会导致大量的否决而没有答案。OTOH，如果任何“真正的”框架也这样做，那么这实际上回答了这个问题。

Answer 1

为此，您不需要特定的单元测试框架。我们利用NUnit在几个不同的变体中使用文件比较与“预期文件”实现了这种自动化测试(但它也适用于任何其他单元测试框架)。

虽然这种功能理论上可以由框架提供，但据我的经验，在大多数现实世界中，实现文本比较器是相当容易的，即使您必须根据您的具体需求调整比较器及其周围的基础设施。因此，我怀疑框架是否能为您提供现成的可重用解决方案，您真的可以用它节省大量代码。

有些事情需要考虑：

• 当实际文本与预期文本的比较失败时，请确保收到一条合理的错误消息，告知测试人员故障发生的确切位置。对于某些场景，只记录不同的第一行可能就足够了，对于其他情况，可能需要记录所有不同的行和发生的差异。如果文本文件是XML或JSON文件，则可能需要以不同的方式显示差异或它们的位置。
• 确保您的测试不会以这种方式变得脆弱--文本比较器可能必须容忍输出中的某些更改，这取决于具体情况。
• 确保测试集可以很容易地扩展和更新。最好有一个文件夹"expected_output“(在版本控制下)和一个文件夹"actual_output”(而不是在版本控制下)，当它需要更新预期的输出时，只需将特定文件从“实际”文件夹复制到“预期”文件夹。

请注意，如果您想要执行TDD，这些类型的测试不是帮助您的测试，它们不能替代“真正的”单元测试。然而，它们可能是对“后测试”策略的合理支持，以便在代码被扩展或重构时找到回归，但是以前输入数据的行为不应该改变。

Answer 2

有一类测试称为批准，它将实际值与手动批准的最后一个良好状态进行比较。https://github.com/approvals快照测试也有一个类似的概念，如注释中提到的。我看到了在各种测试框架中实现的批准测试。