测试🧪#

本节概述了在 Arrow 中进行单元测试所需的步骤。

我们在 Python 中使用 pytest 进行单元测试。有关所需软件包的更多信息，请参阅Python 单元测试部分。

结构

PyArrow 中的测试布局遵循 pytest “作为应用程序代码一部分的测试”结构

pyarrow/
    __init__.py
    csv.py
    dataset.py
    ...
    tests/
        __init__.py
        test_csv.py
        test_dataset.py
        ...

Parquet 的测试位于单独的文件夹 pyarrow/tests/parquet/ 中。

运行测试

要运行特定的单元测试，请在 arrow/python 文件夹的终端中使用此命令

$ pytest pyarrow/tests/test_file.py -k test_your_unit_test

运行一个文件中的所有测试

$ pytest pyarrow/tests/test_file.py

运行所有测试

$ pytest pyarrow

您还可以使用 python -m pytest [...] 运行测试，这几乎等同于直接使用 pytest [...]，不同之处在于通过 python 调用也会将当前目录添加到 sys.path，并且在某些情况下，如果 pytest [...] 导致 ImportError，可能会有所帮助。

重新编译 PyArrow 或 Arrow C++

如果测试开始失败，请尝试重新编译 PyArrow 或 Arrow C++。请参阅 PyArrow 选项卡下构建其他 Arrow 库部分中的注意事项。

夹具

在 PyArrow 测试文件中可以定义辅助函数和夹具。还使用了其他 pytest 装饰器，例如 @parametrize 或 @skipif。

例如：

  • test_pandas 中的 _alltypes_example 提供了一个包含 100 行所有数据类型的数据框。

  • test_pandas 中的 _check_pandas_roundtrip 断言从 Pandas 经过 pa.Table 或 pa.RecordBatch 再回到 Pandas 是否产生相同的结果。

  • large_buffer 夹具在 test_serialization.py 中为函数 test_primitive_serialization(large_buffer) 提供固定大小的 PyArrow 缓冲区。

因此，最好仔细查看您计划添加测试的文件，看看是否有任何已定义的函数或夹具会有所帮助。

有关 pytest 的更多信息，请访问完整的 pytest 文档

我们在 R 中使用 testthat 进行单元测试。更具体地说，我们使用 testthat 的第三版。在极少数情况下，我们可能需要 testthat 第二版的行为，这由 testthat::local_edition(2) 指示。

结构

期望 testthat 具有常规文件夹结构

tests
 ├── testthat      # test files live here
 └── testthat.R    # runs tests when R CMD check runs (e.g. with devtools::check())

这是使用 testthat 在 R 中进行测试的基本结构。像 testthat.R 这样的文件预计不会经常更改。对于 arrow R 包，testthat.R 还定义了各种测试结果如何在控制台中显示/报告。

通常，R/ 子文件夹中的大多数文件在 tests/testthat 中都有一个对应的测试文件。

运行测试

要在本地运行包中的所有测试，请调用

devtools::test()

在 R 控制台中。或者，您可以使用

$ make test

在 shell 中。

您可以使用以下命令运行您打开的单个测试文件中的测试

devtools::test_active_file()

所有测试也作为我们的持续集成 (CI) 管道的一部分运行。

Arrow R 开发人员指南中也有关于运行测试的部分。

良好实践

通常，对源代码的任何更改都需要附带单元测试。在合并拉取请求之前，所有测试都应通过。

  • 添加功能 -> 添加单元测试

  • 修改功能 -> 更新单元测试

  • 解决错误 -> 在解决错误之前添加单元测试，这有助于证明错误及其修复

  • 性能改进应反映在基准测试中（这也属于测试）

  • 一个例外可能是重构完全由单元测试覆盖的功能

一个好的经验法则是：如果新功能是面向用户或 API 更改，您几乎肯定需要更改测试 — 如果不需要更改测试，则可能意味着测试不正确！如果新功能是重构且没有 API 更改，则可能不需要更改测试。

测试助手

为了补充 testthat 功能，arrow R 包定义了一系列特定的实用函数（称为助手），例如

  • 期望 - 这些以 expect_ 开头，用于比较对象

    • 例如，expect_…_roundtrip() 函数接受输入，将其转换为其他格式（例如 arrow, altrep），然后将其转换回来，确认值相同。

      x <- c(1, 2, 3, NA_real_)
expect_altrep_roundtrip(x, min, na.rm = TRUE)

  • skip_ - 跳过单元测试 - 将它们视为可接受的失败。我们可能希望跳过单元测试的情况

    • skip_if_r_version() - 这是一个特定的 arrow 跳过。例如，我们使用它来跳过 R 版本为 3.5.0 及以下的单元测试 (skip_if_r_version(“3.5.0”))。当我们要测试的功能依赖于 R 3.5.0 版本之后引入的功能（例如 R 3.5.0 中引入但后续版本中有重大添加的向量替代表示形式 Altrep）时，您可能会看到它被使用。作为我们 CI 工作流程的一部分，我们针对不同版本的 R 进行测试，这就是此功能发挥作用的地方。

    • skip_if_not_available() - 另一个特定的 {arrow} 跳过。Arrow (libarrow) 有许多可选功能可以打开或关闭（这发生在构建时）。如果单元测试依赖于此类功能且该功能不可用（即在构建 libarrow 时未选择），则会跳过该测试，而不是出现失败的测试。

    • skip_if_offline() - 不运行需要 Internet 连接的测试

    • skip_on_os() - 用于特定于操作系统的单元测试。

    重要：一旦满足 skip_() 语句的条件，同一 test_that() 测试块中的其他代码行将不会执行。如果 skip 在 test_that() 代码块之外，它将跳过文件的其余部分。

有关 R 中单元测试的更多信息

  • testthat 网站

  • Hadley Wickham 和 Jenny Bryan 的 R 包 书