R 具有三个开发良好的单元测试包,RUnit
、svUnit
和testthat
. Base R 在其包功能中内置了示例,如果它们没有正确解析,则会返回错误。
我信任的人的意见是,单元测试比编写大量示例要好,但是我不能完全指出单元测试中无法在示例中复制的任何特定功能。
在 R 中使用单元测试框架的哪些特性使其优于使用包示例的临时等效框架?
对于那些不是来自 R 世界的人,请注意,每次构建包时都会运行包中每个函数的示例,并且程序员会因任何警告或错误而受苦。
R 具有三个开发良好的单元测试包,RUnit
、svUnit
和testthat
. Base R 在其包功能中内置了示例,如果它们没有正确解析,则会返回错误。
我信任的人的意见是,单元测试比编写大量示例要好,但是我不能完全指出单元测试中无法在示例中复制的任何特定功能。
在 R 中使用单元测试框架的哪些特性使其优于使用包示例的临时等效框架?
对于那些不是来自 R 世界的人,请注意,每次构建包时都会运行包中每个函数的示例,并且程序员会因任何警告或错误而受苦。
使用单元测试框架,您可以测试您可能不想作为示例向最终用户公开的各种事物:
单元测试框架的另一个优点是速度:
我的典型包将包含几十个(如果不是数百个)测试,但只有几个示例真正展示了包的含义。
总之,我用测试来测试,用例子来教育和帮助。
当然,这取决于您拥有哪种示例,但很可能这些示例并未显示如何不使用代码。单元测试还可以测试负面情况下的行为。
单元测试可能测试较小的部分,因此测试更简单的功能。使用框架的测试通常可以在每次代码更改后自动运行。如果您一直依赖某人运行示例,那么它们迟早会在某个关键时刻被遗忘。
测试和示例之间的明显区别之一是测试可以成为开发周期的一部分。在测试驱动开发TDD中,每个新特性都从编写测试开始。
我不会在这里详细介绍 TDD 概念(我讨厌笼统,并且我认为该主题在文献中得到了很好的发展)但是如果您总是通过为接下来要实现的功能创建失败测试来完成编码会话,那么它将是当您想继续开发时,您更容易从中断的地方继续。
运行单元测试通常是完全自动化的,运行起来比手动测试便宜得多(更少的开发时间)。当然,编写它们需要时间,但通常比以后花在手动测试上的时间要少。
如果开发是在团队中完成的,通常最好在服务器上进行自动构建,以确保所有新代码都不会破坏任何东西。如果测试在没有与真人进行任何交互的情况下运行,这也更有可能。
单元测试的优点是会给出一个红色或绿色的答案。您无需检查结果以查看一切是否仍按预期工作。