unit-testing - 关于单元测试库/框架的最佳实践是什么？

Question

上下文

我正在努力为我正在设计的库/框架编写一组单元测试。对于上下文，请将我的库视为一组分层相关对象之上的对象层。

问题

基本上，我正在尝试遵守有关单元测试的原则和最佳实践，如 some posts 中所示here ，但它们似乎与专门对库或框架进行单元测试有关。

例如，一个基本测试关注的是“创建一个工件”。另一个是“移除神器”。但是，由于单元测试应该是独立的并在完成后恢复世界状态，所以这两个测试似乎有些相关:在测试工件创建时，我们需要在测试结束时通过实际清理状态删除它。这意味着工件移除本身是隐式测试的。同样的推理也适用于测试工件移除:为了设置世界以便工件移除是可测试的，我们需要首先创建一个新的工件。

当我们需要对相关子工件的创建和删除进行单元测试时，情况就变得复杂了，为此我们需要相应地设置世界。

我倾向于按顺序执行一组相关的单元测试，以便每个单元测试都是离散的(即只测试一件事，并且只测试一件事)，但取决于顺序中的先前测试以逐步设置世界。然后，我的序列可能如下所示:

[创建工件]->[创建子工件]->[删除子工件]->[删除工件]

根据这一原则，对整个库/框架进行单元测试，并在测试套件的整个运行结束时恢复世界状态。然而，这意味着测试套件中间的任何故障都会“破坏世界”。

有哪些最佳实践和指南可能有助于调和这些相互冲突的需求？

引用资料

What makes a good unit test?

Is it bad form to have unit test calling other unit tests?

Answer 1

“恢复世界状态”是指清理数据库或类似的东西？

在这种情况下，您可能已经进行了一些模拟持久层的单元测试。这将使您能够独立运行单元测试，而不依赖于在测试之间保留状态。

所以剩下的就是其他测试，听起来有点像“黑盒”测试、集成测试，或者任何你想称呼的测试。它们依赖于必须设置、监控、拆除等的外部状态。

您绝对应该期望它们比单元测试更脆弱。

我个人的看法是，一旦您进行了这些测试……这真的取决于情况。你的建议听起来不无道理。

我倾向于构建一套强大的独立单元测试，并依靠您描述的测试进行最终的“粘合测试”。所以它们不是太详细，也不要尝试和练习图书馆的每个方面。