testing.rst

  1.. SPDX-License-Identifier: GPL-2.0
  2.. include:: ../disclaimer-zh_CN.rst
  3
  4:Original: Documentation/rust/testing.rst
  5
  6:翻译:
  7
  8 郭杰 Ben Guo <benx.guo@gmail.com>
  9
 10测试
 11====
 12
 13本文介绍了如何在内核中测试 Rust 代码。
 14
 15有三种测试类型：
 16
 17- KUnit 测试
 18- ``#[test]`` 测试
 19- Kselftests
 20
 21KUnit 测试
 22----------
 23
 24这些测试来自 Rust 文档中的示例。它们会被转换为 KUnit 测试。
 25
 26使用
 27****
 28
 29这些测试可以通过 KUnit 运行。例如，在命令行中使用 ``kunit_tool`` （ ``kunit.py`` ）::
 30
 31	./tools/testing/kunit/kunit.py run --make_options LLVM=1 --arch x86_64 --kconfig_add CONFIG_RUST=y
 32
 33或者，KUnit 也可以在内核启动时以内置方式运行。获取更多 KUnit 信息，请参阅
 34Documentation/dev-tools/kunit/index.rst。
 35关于内核内置与命令行测试的详细信息，请参阅 Documentation/dev-tools/kunit/architecture.rst。
 36
 37要使用这些 KUnit 文档测试，需要在内核配置中启用以下选项::
 38
 39	CONFIG_KUNIT
 40	   Kernel hacking -> Kernel Testing and Coverage -> KUnit - Enable support for unit tests
 41	CONFIG_RUST_KERNEL_DOCTESTS
 42	   Kernel hacking -> Rust hacking -> Doctests for the `kernel` crate
 43
 44KUnit 测试即文档测试
 45********************
 46
 47文档测试（ *doctests* ）一般用于展示函数、结构体或模块等的使用方法。
 48
 49它们非常方便，因为它们就写在文档旁边。例如：
 50
 51.. code-block:: rust
 52
 53	/// 求和两个数字。
 54	///
 55	/// ```
 56	/// assert_eq!(mymod::f(10, 20), 30);
 57	/// ```
 58	pub fn f(a: i32, b: i32) -> i32 {
 59	    a + b
 60	}
 61
 62在用户空间中，这些测试由 ``rustdoc`` 负责收集并运行。单独使用这个工具已经很有价值，
 63因为它可以验证示例能否成功编译（确保和代码保持同步），
 64同时还可以运行那些不依赖内核 API 的示例。
 65
 66然而，在内核中，这些测试会转换成 KUnit 测试套件。
 67这意味着文档测试会被编译成 Rust 内核对象，从而可以在构建的内核环境中运行。
 68
 69通过与 KUnit 集成，Rust 的文档测试可以复用内核现有的测试设施。
 70例如，内核日志会显示::
 71
 72	KTAP version 1
 73	1..1
 74	    KTAP version 1
 75	    # Subtest: rust_doctests_kernel
 76	    1..59
 77	    # rust_doctest_kernel_build_assert_rs_0.location: rust/kernel/build_assert.rs:13
 78	    ok 1 rust_doctest_kernel_build_assert_rs_0
 79	    # rust_doctest_kernel_build_assert_rs_1.location: rust/kernel/build_assert.rs:56
 80	    ok 2 rust_doctest_kernel_build_assert_rs_1
 81	    # rust_doctest_kernel_init_rs_0.location: rust/kernel/init.rs:122
 82	    ok 3 rust_doctest_kernel_init_rs_0
 83	    ...
 84	    # rust_doctest_kernel_types_rs_2.location: rust/kernel/types.rs:150
 85	    ok 59 rust_doctest_kernel_types_rs_2
 86	# rust_doctests_kernel: pass:59 fail:0 skip:0 total:59
 87	# Totals: pass:59 fail:0 skip:0 total:59
 88	ok 1 rust_doctests_kernel
 89
 90文档测试中，也可以正常使用 `? <https://doc.rust-lang.org/reference/expressions/operator-expr.html#the-question-mark-operator>`_ 运算符，例如：
 91
 92.. code-block:: rust
 93
 94	/// ```
 95	/// # use kernel::{spawn_work_item, workqueue};
 96	/// spawn_work_item!(workqueue::system(), || pr_info!("x\n"))?;
 97	/// # Ok::<(), Error>(())
 98	/// ```
 99
100这些测试和普通代码一样，也可以在 ``CLIPPY=1`` 条件下通过 Clippy 进行编译，
101因此可以从额外的 lint 检查中获益。
102
103为了便于开发者定位文档测试出错的具体行号，日志会输出一条 KTAP 诊断信息。
104其中标明了原始测试的文件和行号（不是 ``rustdoc`` 生成的临时 Rust 文件位置）::
105
106	# rust_doctest_kernel_types_rs_2.location: rust/kernel/types.rs:150
107
108Rust 测试中常用的断言宏是来自 Rust 标准库（ ``core`` ）中的 ``assert!`` 和 ``assert_eq!`` 宏。
109内核提供了一个定制版本，这些宏的调用会被转发到 KUnit。
110和 KUnit 测试不同的是，这些宏不需要传递上下文参数（ ``struct kunit *`` ）。
111这使得它们更易于使用，同时文档的读者无需关心底层用的是什么测试框架。
112此外，这种方式未来也许可以让我们更容易测试第三方代码。
113
114当前有一个限制：KUnit 不支持在其他任务中执行断言。
115因此，如果断言真的失败了，我们只是简单地把错误打印到内核日志里。
116另外，文档测试不适用于非公开的函数。
117
118作为文档中的测试示例，应当像 “实际代码” 一样编写。
119例如：不要使用 ``unwrap()`` 或 ``expect()``，请使用 `? <https://doc.rust-lang.org/reference/expressions/operator-expr.html#the-question-mark-operator>`_ 运算符。
120更多背景信息，请参阅：
121
122	https://rust.docs.kernel.org/kernel/error/type.Result.html#error-codes-in-c-and-rust
123
124``#[test]`` 测试
125----------------
126
127此外，还有 ``#[test]`` 测试。与文档测试类似，这些测试与用户空间中的测试方式也非常相近，并且同样会映射到 KUnit。
128
129这些测试通过 ``kunit_tests`` 过程宏引入，该宏将测试套件的名称作为参数。
130
131例如，假设想要测试前面文档测试示例中的函数 ``f``，我们可以在定义该函数的同一文件中编写：
132
133.. code-block:: rust
134
135	#[kunit_tests(rust_kernel_mymod)]
136	mod tests {
137	    use super::*;
138
139	    #[test]
140	    fn test_f() {
141	        assert_eq!(f(10, 20), 30);
142	    }
143	}
144
145如果我们执行这段代码，内核日志会显示::
146
147	    KTAP version 1
148	    # Subtest: rust_kernel_mymod
149	    # speed: normal
150	    1..1
151	    # test_f.speed: normal
152	    ok 1 test_f
153	ok 1 rust_kernel_mymod
154
155与文档测试类似， ``assert!`` 和 ``assert_eq!`` 宏被映射回 KUnit 并且不会发生 panic。
156同样，支持 `? <https://doc.rust-lang.org/reference/expressions/operator-expr.html#the-question-mark-operator>`_ 运算符，
157测试函数可以什么都不返回（单元类型 ``()``）或 ``Result`` （任何 ``Result<T, E>``）。例如：
158
159.. code-block:: rust
160
161	#[kunit_tests(rust_kernel_mymod)]
162	mod tests {
163	    use super::*;
164
165	    #[test]
166	    fn test_g() -> Result {
167	        let x = g()?;
168	        assert_eq!(x, 30);
169	        Ok(())
170	    }
171	}
172
173如果我们运行测试并且调用 ``g`` 失败，那么内核日志会显示::
174
175	    KTAP version 1
176	    # Subtest: rust_kernel_mymod
177	    # speed: normal
178	    1..1
179	    # test_g: ASSERTION FAILED at rust/kernel/lib.rs:335
180	    Expected is_test_result_ok(test_g()) to be true, but is false
181	    # test_g.speed: normal
182	    not ok 1 test_g
183	not ok 1 rust_kernel_mymod
184
185如果 ``#[test]`` 测试可以对用户起到示例作用，那就应该改用文档测试。
186即使是 API 的边界情况，例如错误或边界问题，放在示例中展示也同样有价值。
187
188``rusttest`` 宿主机测试
189-----------------------
190
191这类测试运行在用户空间，可以通过 ``rusttest`` 目标在构建内核的宿主机中编译并运行::
192
193	make LLVM=1 rusttest
194
195当前操作需要内核 ``.config``。
196
197目前，它们主要用于测试 ``macros`` crate 的示例。
198
199Kselftests
200----------
201
202Kselftests 可以在 ``tools/testing/selftests/rust`` 文件夹中找到。
203
204测试所需的内核配置选项列在 ``tools/testing/selftests/rust/config`` 文件中，
205可以借助 ``merge_config.sh`` 脚本合并到现有配置中::
206
207	./scripts/kconfig/merge_config.sh .config tools/testing/selftests/rust/config
208
209Kselftests 会在内核源码树中构建，以便在运行相同版本内核的系统上执行测试。
210
211一旦安装并启动了与源码树匹配的内核，测试即可通过以下命令编译并执行::
212
213	make TARGETS="rust" kselftest
214
215请参阅 Documentation/dev-tools/kselftest.rst 文档以获取更多信息。