你认为单元测试是向你的程序员展示如何使用API​​的好方法吗？

Question

您认为单元测试是向同事程序员展示如何使用API​​的好方法吗？

我正在听Stackoverflow Podcast this week，我现在意识到单元测试在所有情况下都不合适（例如，如果你进行100％的代码覆盖，它可能会花费你的时间）。我同意这一点，因为我曾经遭受过“OCD代码覆盖障碍”的困扰，现在已经修好了我的方法。

然而，为了进一步了解我对该主题的了解，我想知道单元测试是否是引入不熟悉项目API的新程序员的好方法。 （这肯定比编写文档更容易......虽然我喜欢以后的文档......）

Answer 1

我认为单元测试是记录API的绝佳方式。它不一定取代好的评论或API文档，但它是一种非常实用的方法来帮助人们深入了解代码的细节。此外，良好的单元测试可以促进良好的设计，因此您的代码很容易理解。

Answer 2

单位测试，IMO，不能以任何方式替代文档。您编写测试以查找和练习代码的极端情况，以确保满足所有边界条件。这些通常不是给予试图了解该方法如何工作的人的最合适的例子。

您通常也不会详细解释为什么在单元测试中发生了什么。

最后，单元测试的内容通常不像文档生成工具那样可访问，并且通常与他们正在测试的代码分开（尽管像Python的doctests那样奇怪）。

Answer 3

良好的文档通常包括很好的例子。我很难想象一组更好的例子，而不是那些显示出正确实现的预期的例子！

此外，维护是一个至关重要的问题。通过添加暴露缺陷的测试来处理缺陷，然后通过使测试成功而不会使先前的测试失败，这是一种很好的做法。如果单元测试被视为文档的一部分，那么这个新测试将成为文档更改日志的一部分，从而帮助后续开发人员从经验中学习。

Answer 4

没有。测试可以用作辅助参考，它们至少具有实际编译的示例的好处，但它们不能替代良好的API文档。

谨防那些声称几乎神秘的单位测试权力的狂热者说“测试是设计”，“测试是规范”，“测试是文档”。不。测试是测试，他们没有给你借口在其他地方偷工减料。

Answer 5

文档不应该用单位测试代码代替。

文档面向试图使用和理解您的API的程序员。

单元测试旨在覆盖极端情况，虽然它们应该记录在案，但不应该成为API新用户的关注点。

文档应该逐渐增加复杂性，单元测试应尽可能简单，尽可能复杂，以便测试功能。

例如，您可能有许多单元测试看起来非常相似，但有微小差异，只是为了涵盖各种奇怪的角落情况并断言正确的行为。

不要让你的API用户破译这些单元测试，找出差异，并弄清楚为什么这会产生不同（或可能相同）的行为并不是一个好的教学辅助。

单元测试适用于api的维护者，程序员将修复其中的错误，或者为其添加新功能，或重构它，或者....

文档适用于将使用您的API的程序员。

这些目标受众不同。

一个细微的差别可能是，虽然单元测试断言当一个函数传递一个负值时，它会做一些特定的事情，文档会反过来详细介绍为什么这个特定的解决方案被选中了。如果所有文档都只是将代码重写为英文，那么它没有多大意义，因此文档通常比代码更详细和更具说明性。

Answer 6

虽然不是替代品，但单元测试可以成为演示类或API使用的绝佳方式，特别是对于执行测试的代码量极少的库函数。

例如，数学库经过单元测试。如果有人有问题（例如如何查找有关光线/体积交叉点的信息），那么我发送的第一个地方就是单元测试。

（为什么我们测试一些可以被认为是如此稳定的东西？一方面我们支持五个平台并逐步添加基于基准测试的特定于平台的SIMD实现，另一方面，单元测试为添加新平台提供了一个很好的框架或者功能）。

FWIW我认为本周播客对单元测试的讨论是开始的。单元测试（和测试驱动开发）是开发应用程序组件的好方法，但是为了测试应用程序本身，您很快就会达到测试所需的代码变得不成比例和脆弱的程度。