测试 🧪#

本节概述了在 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 库 部分的说明。

Fixtures

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

例如

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

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

  • large_buffer fixture 向 test_serialization.py 中的函数 test_primitive_serialization(large_buffer) 提供固定大小的 PyArrow 缓冲区。

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

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

我们在 R 中使用 testthat 进行单元测试。更具体地说，我们使用 testthat 的第 3 版。在极少数情况下，我们可能希望 testthat 的第 2 版的行为，这由 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 开发者指南中也有关于运行测试的部分。

良好实践

一般来说，任何对源代码的更改都需要附带单元测试。在合并 pull request 之前，所有测试都应通过。

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

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

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

  • 性能改进应在基准测试（它们也是测试）中体现

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

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

测试辅助函数

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

  • expectations - 这些以 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 特定的 skip 函数。例如，当 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} 特定的 skip 函数。Arrow (libarrow) 有许多可选功能，可以开启或关闭（这在构建时发生）。如果单元测试依赖于某个功能且该功能不可用（即构建 libarrow 时未选择该功能），则会跳过测试，而不是测试失败。

    • skip_if_offline() - 不会运行需要互联网连接的测试

    • skip_on_os() - 用于 OS 特定的单元测试。

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

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

  • testthat 网站

  • Hadley Wickham 和 Jenny Bryan 合著的 R Packages 一书