r - 在 R 中跳过对 M1mac 的测试

Question

根据 Carl Boettiger 在 this thread 中的说法, “...当测试失败时。与 Solaris 一样，当上游依赖项安装在平台上但实际上并未运行时，可能会发生其中一些失败。”我的代码在 M1mac 上在数值上失败了，但在其他平台上却没有，同时对返回非常小的值的函数使用 stats::integrate。

我应该跳过 M1mac (arm64) 上的测试吗？

require(testthat)
test_that("correct numeric solution", {
     skip_on_os("mac", arch = "aarch64")

     # code of the test using expect_equal()
})

或者，调整 expect_equal() 中的 tolerance 参数是否可以帮助解决一个系统上的特定问题？如果是，如果我的结果是 1e-9(现在使用 tolerance = 1e-6，并且测试失败)，tolerance 应该更改为什么值？

更笼统地说，CRAN 上的 R 包最佳编码实践(或长期解决方案)是什么，以解决特定测试在一个操作系统上失败的问题？

Answer 1

其他程序员是怎么做的

我犹豫要不要谈论规范包，但有一些相当知名的包会跳过某些操作系统进行特定测试:

• https://github.com/chasemc/electricShine
• https://github.com/ropensci/arkdb

上面存储库中的几个示例:

1. Example 1.跳过 Solaris 平台上的核心功能测试。

2. Example 2.跳过 Linux 的安装测试(此项目中的其他测试似乎涵盖所有操作系统)。

文档说了什么

This是 testthat 包的官方文章。它清楚地说明了在什么情况下你最好跳过测试；然而，这些陈述往往更具建议性而非强制性:

You’re testing a web service that occasionally fails, and you don’t want to run the tests on CRAN. Or maybe the API requires authentication, and you can only run the tests when you’ve securely distributed some secrets.

You’re relying on features that not all operating systems possess, and want to make sure your code doesn’t run on a platform where it doesn’t work. This platform tends to be Windows, since amongst other things, it lacks full utf8 support.

You’re writing your tests for multiple versions of R or multiple versions of a dependency and you want to skip when a feature isn’t available. You generally don’t need to skip tests if a suggested package is not installed. This is only needed in exceptional circumstances, e.g. when a package is not available on some operating system.

我已经突出显示了所有关于操作系统的文章。根据您的问题，我可以得出结论，您的情况符合“您依赖的功能并非所有操作系统都具备”的说法，因为您很可能遇到了 M1 Mac 操作系统中的错误 自 macOS build has a slightly different way of calculating extended-precision floating-point numbers ^[1]:

The ‘native’ build is a little faster (and for some tasks, considerably so) but may give different numerical results from the far more common ‘x86_64’ platforms (on macOS and other OSes) as ARM hardware lacks extended-precision floating-point operations.

意识形态坚持什么

值得我们花时间回顾一下为什么首先要发明单元测试。

尽管所有关于维基百科不可靠的讨论，我相信这个来源被我的绝大多数同事认为是“规范的”，which states :

Unit tests are typically automated tests written and run by software developers to ensure that a section of an application (known as the "unit") meets its design and behaves as intended.

为了从意识形态的角度回答你的问题，我们只需要回答一个问题:你的代码目前是否按预期工作？

如果您认为您的功能对于最终用户来说足够全面，即使它部分不能在特定操作系统上正常工作，请随时跳过测试。

如果不是，则意味着您的代码包含需要在投入生产之前修复的错误。在这种情况下，一旦您修复它，测试应该会在您有问题的操作系统上成功。

My code fails numerically on M1mac, but not on other platforms, while using stats::integrate on functions returning very small values.

我自己的(可能有偏见的)观点

根据你的话，很难理解是哪一个，但我相信如果你的包对 99.99% 的观众来说是可行的，请继续跳过这个烦人的测试，只剩下 0.01 个可能的百分位数环境。也许您应该在 README.MD 的某个地方注意到您的包有这个问题。

这样一来，其他开发人员就会意识到这一点，而那些使用 M1Mac OS 的开发人员很可能会找到解决方法或自行修复它 - 以防您正在创建一个开源项目。

---

注意事项:

[1]。感谢Roland的评论，我已经更新了我的答案。