常见问题¶
这与 Autotest、kselftest 等有什么不同？¶
KUnit 是一个单元测试框架。Autotest、kselftest（以及其他一些）不是。
单元测试旨在隔离地测试单个代码单元，因此得名单元测试。单元测试应该是最细粒度的测试，并且应该允许测试代码中所有可能的代码路径。只有当被测代码很小并且没有任何在测试控制之外的外部依赖项（如硬件）时，这才有可能。
目前没有可用于内核的测试框架，这些框架不需要将内核安装在测试机器上或虚拟机中。所有测试框架都要求测试在用户空间编写并在被测内核上运行。Autotest、kselftest 和其他一些也是如此，这使得它们中的任何一个都不被视为单元测试框架。
KUnit 是否支持在 UML 以外的架构上运行？¶
是的，大部分是。
在大多数情况下，KUnit 核心框架（我们用来编写测试的框架）可以编译到任何架构。它的编译方式与内核的其他部分一样，并在内核启动时运行，或者当作为模块构建时，在模块加载时运行。但是，有些基础设施（如 KUnit 包装器（tools/testing/kunit/kunit.py））可能不支持某些架构（请参阅 在 QEMU 上运行测试）。
简而言之，是的，你可以在其他架构上运行 KUnit，但这可能比在 UML 上使用 KUnit 需要更多的工作。
有关详细信息，请参阅 为其他架构编写测试。
单元测试和其他类型的测试之间有什么区别？¶
Linux 内核的大多数现有测试都将归类为集成测试或端到端测试。
单元测试旨在隔离地测试单个代码单元。单元测试应该是最细粒度的测试，因此允许测试被测代码中所有可能的代码路径。只有当被测代码很小并且没有任何在测试控制之外的外部依赖项（如硬件）时，这才有可能。
集成测试测试最少组件集之间的交互，通常只有两到三个。例如，有人可能会编写一个集成测试来测试驱动程序和硬件之间的交互，或者测试内核提供的用户空间库和内核本身之间的交互。但是，这些测试之一可能不会测试整个内核以及硬件交互和与用户空间的交互。
端到端测试通常从被测代码的角度测试整个系统。例如，有人可能会通过在生产硬件上使用生产用户空间安装内核的生产配置来编写内核的端到端测试，然后尝试执行某些取决于硬件、内核和用户空间之间交互的行为。
KUnit 无法正常工作，我该怎么办？¶
不幸的是，有很多事情可能会中断，但这里有一些可以尝试的方法。
使用
--raw_output参数运行./tools/testing/kunit/kunit.py run。这可能会显示被 kunit_tool 解析器隐藏的详细信息或错误消息。尝试独立运行
kunit.py config、kunit.py build和kunit.py exec，而不是运行kunit.py run。这有助于跟踪问题发生的位置。（如果你认为解析器有问题，你可以使用kunit.py parse手动针对stdin或文件运行它。）直接运行 UML 内核通常可以显示
kunit_tool忽略的问题或错误消息。这应该像在构建 UML 内核（例如，使用kunit.py build）后运行./vmlinux一样简单。请注意，UML 有一些不寻常的要求（例如，主机必须挂载 tmpfs 文件系统），并且在静态构建并且主机启用了 KASLR 时，过去曾出现过问题。（在旧版主机内核上，你可能需要运行setarch `uname -m` -R ./vmlinux以禁用 KASLR。）确保内核的 .config 具有
CONFIG_KUNIT=y和至少一个测试（例如CONFIG_KUNIT_EXAMPLE_TEST=y）。kunit_tool 将保留其 .config，因此你可以在运行kunit.py run后查看使用了哪些配置。它还会保留你可能做出的任何配置更改，因此你可以使用make ARCH=um menuconfig或类似命令启用/禁用内容，然后重新运行 kunit_tool。尝试在运行
kunit.py run之前运行make ARCH=um defconfig。这可能有助于清理任何可能导致问题的剩余配置项。最后，尝试在 UML 之外运行 KUnit。KUnit 和 KUnit 测试可以构建到任何内核中，也可以构建为模块并在运行时加载。这样做应该可以让你确定是否是 UML 导致了你看到的问题。当测试内置时，它们将在内核启动时执行，模块将在加载时自动执行关联的测试。测试结果可以从
/sys/kernel/debug/kunit/<test suite>/results中收集，并且可以使用kunit.py parse进行解析。有关更多详细信息，请参阅 在 QEMU 上运行测试。
如果以上技巧都无济于事，你始终可以发送电子邮件给 kunit-dev@googlegroups.com 以报告任何问题。