正式单元测试的优点仅仅是写了很多例子？

Question

R有三个完善的单元测试包，RUnit，svUnit和testthat。 Base R在其包功能中内置了示例，如果它们无法正确解析，则会返回错误。

我信任的人的意见是单元测试比编写大量示例更好，但我无法完全理解单元测试中的任何特定功能，这些功能无法在示例中复制。

在R中使用单元测试框架的哪些特性使其优于使用包示例的 ad hoc 等效？

对于那些不是来自R世界的人，请注意，每次构建软件包时都会运行软件包中每个函数的示例，并且程序员会因任何警告或错误而受到影响。

Answer 1

使用单元测试框架，您可以测试您可能不希望向最终用户公开的各种事物：

• 函数是否因输入错误而抛出正确的错误？单元测试框架将捕获错误，从而通过测试。
• 单元测试应该旨在获得非常高的代码覆盖率。您可能希望测试所有输入参数的所有组合。

单元测试框架的另一个优点是速度：

• 例如，您可以选择性地在给定文件中运行测试。相反，根据包输出意味着您需要构建并检查整个包。
• 这样可以更快地识别错误并加快开发周期。

我的典型软件包将包含数十个（如果不是数百个）测试，但只有几个示例可以真正展示软件包的内容。

总之，我使用测试来测试，以及教育和帮助的例子。

Answer 2

当然，这取决于您拥有哪种示例，但最有可能的示例并未显示如何不使用代码。单元测试也可以测试负面情况下的行为。

单元测试可能会测试较小的部件，因此功能更简单。使用框架的测试通常可以在每次代码更改后自动运行。如果你依赖于经常运行这些例子的人，迟早会在某个关键时刻忘记这些例子。

Answer 3

tests 和 examples 之间的一个明显区别是，测试可以成为开发周期的一部分。在测试驱动开发 TDD 中，每个新功能都从编写测试开始。

我不会在这里详细介绍TDD概念（我讨厌一般性，我认为这个主题在文献中得到了很好的发展）但是如果你总是完成一个编码会话 通过为该功能创建失败的测试 你想接下来实施，你会更容易选择 当你想继续发展的时候，你就离开了。

Answer 4

运行单元测试通常是完全自动化的，比手动测试更便宜（更少的开发时间）。当然，编写它们需要时间，但通常比以后在手动测试上花费的时间更少。

如果在团队中进行开发，那么在服务器上进行自动构建通常也是很好的，以确保所有新代码都不会破坏任何内容。如果测试在没有与真人进行任何交互的情况下运行，这也更有可能。

Answer 5

单元测试的优点是出现一个单独的红色或绿色答案。您无需检查结果以查看是否所有内容仍按预期工作。