Linux 內核 KUnit 單元測試架構原理、kunit.py 實戰(zhàn)與測試編寫全解【免費下載鏈接】linuxLinux kernel source tree項目地址: https://gitcode.com/GitHub_Trending/li/linux本文以 Linux 內核官方 KUnit 文檔Documentation/dev-tools/kunit/為主體系統(tǒng)講解內核單元測試框架 KUnit 的兩層架構內核內測試框架 kunit_tool命令行封裝、kunit.py的配置/構建/執(zhí)行/解析完整流程以及從編寫第一個測試到參數(shù)化、資源清理、靜態(tài)函數(shù)測試等進階技巧。讀完本文你可以在本倉庫中直接運行 KUnit 測試、為自己的內核子系統(tǒng)編寫可維護的單元測試并理解測試套件如何通過.kunit_test_suites鏈接段在開機時被自動發(fā)現(xiàn)和執(zhí)行。一、KUnit 是什么內核單元測試框架的定位KUnitKernel Unit Testing Framework是 Linux 內核提供的一套通用單元測試框架。根據(jù) KUnit 文檔索引 的介紹使用 KUnit 可以把測試用例組織成測試套件test suite測試要么在內核開機時運行內置編譯要么作為模塊加載時運行KUnit 會自動把失敗的測試用例標記并在內核日志中報告結果以KTAPKernel - Test Anything Protocol格式輸出KTAP 基于 TAP14見 KTAP 文檔它的設計靈感來自 JUnit、Python 的 unittest.mock 和 GoogleTest/GoogleMockC 單元測試框架。幾個關鍵特性決定了 KUnit 的適用邊界測試代碼是內核代碼KUnit 測試用 C 語言編寫是內核的一部分測試對象是內核實現(xiàn)本身某個 C 函數(shù)、文件system邏輯、系統(tǒng)調用、內存管理、設備驅動等。白盒測試KUnit 運行在內核態(tài)可以訪問內部功能不局限于暴露給用戶態(tài)的接口?？煳臋n指出除編譯時間外從調用到完成KUnit 可以在不到 10 秒內運行約 100 個測試。前置條件任何支持 Linux 內核的硬件都可以被測內核版本需要 5.5 及以上。單元測試本身的定義也值得明確單元測試以最小粒度測試一段獨立代碼只有在被測代碼足夠小、且不依賴測試無法控制的外部因素如硬件時才能覆蓋所有代碼路徑。文檔給出的編寫單元測試的經典模式是Arrange-Act-AssertArrange在測試開始時準備數(shù)據(jù)初始化語句或對象Act調用被測函數(shù)/代碼Assert驗證結果或狀態(tài)符合預期。單元測試的收益文檔總結為四點長期提升測試與開發(fā)速度、在早期發(fā)現(xiàn)缺陷從而降低修復成本、提升代碼質量、鼓勵編寫可測試的代碼。二、KUnit 架構兩層結構架構文檔 把 KUnit 劃分為兩部分內核內測試框架In-Kernel Testing Framework與kunit_tool命令行測試封裝。2.1 測試用例Test Case測試用例是 KUnit 的基本單元其函數(shù)簽名是void (*)(struct kunit *test)。每個測試用例都會收到一個struct kunit上下文對象斷言宏和其他 KUnit 工具都依賴該對象。其中兩個字段有專門用途-privsetup 函數(shù)可用它保存任意的測試用戶數(shù)據(jù)-param_value參數(shù)化測試中存放當前參數(shù)值。2.2 測試套件Test Suite測試套件是測試用例的集合用struct kunit_suite表示。一個典型定義如下static struct kunit_case example_test_cases[] { KUNIT_CASE(example_test_foo), KUNIT_CASE(example_test_bar), KUNIT_CASE(example_test_baz), {} }; static struct kunit_suite example_test_suite { .name example, .init example_test_init, .exit example_test_exit, .test_cases example_test_cases, }; kunit_test_suite(example_test_suite);執(zhí)行順序為先調用example_test_init然后依次運行三個用例每個用例之后調用example_test_exit。末尾的kunit_test_suite(example_test_suite)負責把套件注冊進 KUnit 框架。示例測試 中詳細注釋了這套執(zhí)行順序suite_init - init - test_case[i] - exit - suite_exit可作為參考實現(xiàn)。2.3 執(zhí)行器.kunit_test_suites鏈接段執(zhí)行器executor負責在開機時列出并運行內置 KUnit 測試。其核心機制是鏈接段所有套件被存放在名為.kunit_test_suites的鏈接段中該段是一個struct kunit_suite *指針數(shù)組由kunit_test_suites()宏填充。從源碼看include/kunit/test.h 中__kunit_test_suites通過__used __section(.kunit_test_suites)把數(shù)組放入該段而kunit_test_suite(suite)只是kunit_test_suites(suite)的簡化形式鏈接腳本中段的起止符號由 include/asm-generic/vmlinux.lds.h 的KUNIT_TABLE()定義使用BOUNDED_SECTION_POST_LABEL(.kunit_test_suites, __kunit_suites, _start, _end)生成有界區(qū)間的邊界符號內核啟動后lib/kunit/executor.c 用段的起止地址遍歷該數(shù)組并運行全部測試調用入口在 lib/kunit/executor.c 的__kunit_test_suites_init(suite_set-start, num_suites, autorun)當以模塊方式編譯時kunit_test_suites()宏轉而定義一個module_init()函數(shù)在模塊加載時直接運行本編譯單元內的所有測試而不走 executor 路徑。__kunit_test_suites_init/__kunit_test_suites_exit的實現(xiàn)位于 lib/kunit/test.c均以EXPORT_SYMBOL_GPL導出供模塊使用。另外為了讓個別測試的嚴重錯誤不波及其他測試或內核每個 KUnit 用例在獨立的線程上下文中執(zhí)行實現(xiàn)見 lib/kunit/try-catch.c 中的kunit_try_catch_run()。2.4 斷言宏與結果上報所有期望/斷言統(tǒng)一格式化為KUNIT_{EXPECT|ASSERT}_op_MSGEXPECT期望失敗時把測試標記為失敗并記錄日志測試繼續(xù)執(zhí)行后續(xù)期望ASSERT斷言失敗立即終止當前用例。底層調用鏈為__kunit_abort()→kunit_try_catch_throw()→kthread_complete_and_exit()即直接終止該用例對應的 kthread因此斷言可以調用在任何位置而不像其他框架那樣只能寫在測試函數(shù)內op常見取值TRUE、EQ、NOT_ERR_OR_NULL等[_MSG]變體在失敗時打印自定義消息。結果上報方面KUnit 以 KTAP 格式輸出executor 會把 KTAP 結果寫入 dmesg配置后還會寫入 debugfs。2.5 kunit_tool命令行封裝kunit_tool是一個 Python 腳本入口為 tools/testing/kunit/kunit.py用于按正確順序執(zhí)行配置 → 構建 → 執(zhí)行 → 解析四個階段。從目錄結構看其內部模塊分工清晰模塊職責kunit.py命令行入口與子命令分發(fā)kunit_config.py解析.kunitconfig與.config保證前者是后者的子集kunit_kernel.py調用make含olddefconfig構建內核kunit_parser.py / kunit_printer.py解析 KTAP 輸出并格式化摘要kunit_json.py / kunit_junit.pyJSON / JUnit XML 結果輸出qemu_config.py 及 qemu_configs/各架構 QEMU 運行參數(shù)定義configs/default.configKUnit 默認配置集四個子命令的行為config從.kunitconfig加上架構特定選項生成.config它會確認.config是.kunitconfig的超集否則合并二者并運行make olddefconfig重新生成以此校驗 Kconfig 依賴在.kunitconfig中是否聲明完整build按當前.config和架構相關選項調用make構建內核并報告錯誤exec直接UML或通過 QEMU 啟動內核執(zhí)行測試從 stdout 讀取日志并交給parseparse從內核日志中提取 KTAP 輸出、解析結果并打印摘要失敗測試會附帶診斷輸出。三、使用 kunit.py 運行測試3.1 一鍵運行在倉庫根目錄執(zhí)行./tools/testing/kunit/kunit.py run正常情況下會看到Configuring KUnit Kernel ... Building KUnit Kernel ... Starting KUnit Kernel ...之后逐條打印測試通過/失敗。常用組合./tools/testing/kunit/kunit.py run --timeout30 --jobsnproc --all--timeout測試運行的最大時長秒不含構建時間--jobs并行編譯的線程數(shù)。新手常見報錯The source tree is not clean, please run make ARCHum mrproper。原因是 kunit.py 默認通過--build_dir指定.kunit作為make Ooutput/dir的構建目錄執(zhí)行樹外構建前源碼樹必須是干凈的make ARCHum mrproper可解決但注意它會刪除當前配置和所有生成文件。且按 admin-guide 說明 中內核構建目錄的慣例O目錄一旦使用就要在所有make調用中保持一致。3.2 自定義 Kconfig.kunitconfigkunit_tool 默認以最小配置default.config等默認值運行所有可達測試本倉庫的 tools/testing/kunit/configs/default.config 內容非常簡潔CONFIG_KUNITy CONFIG_KUNIT_EXAMPLE_TESTy CONFIG_KUNIT_ALL_TESTSy CONFIG_SPIy要運行特定測試集有四種方式見 start 指南a. 直接編輯.kunit/.kunitconfig。該文件應包含運行目標測試所需的全部 Kconfig 選項及其依賴可以刪掉CONFIG_KUNIT_ALL_TESTS以避免開啟大量無關測試。尚未運行過kunit.py run時可先執(zhí)行下面命令生成默認配置cd $PATH_TO_LINUX_REPO tools/testing/kunit/kunit.py config cat .kunit/.kunitconfig注意.kunitconfig位于--build_dir默認.kunit下。b. 在默認配置上追加選項例如啟用內核鏈表測試./tools/testing/kunit/kunit.py run \ --kconfig_add CONFIG_LIST_KUNIT_TESTyc. 直接指定源碼樹內現(xiàn)成的.kunitconfig文件例如只跑 FAT 和 EXT4 測試./tools/testing/kunit/kunit.py run \ --kunitconfig ./fs/fat/.kunitconfig \ --kunitconfig ./fs/ext4/.kunitconfigd. 直接編輯.config或make menuconfig O.kunit只要它是.kunitconfig的超集kunit.py 不會覆蓋你的改動。找到滿意的配置后可以用make savedefconfig O.kunit把.kunit/defconfig復制為新的.kunitconfig保存。此外運行前 kunit_tool 會校驗.kunitconfig中的每個選項都已存在于.config中缺少依賴會給出警告。3.3 按名字過濾測試向run/exec命令傳一個 glob 過濾器語法見glob(7)手冊即可選擇要執(zhí)行的用例。過濾器含.時被解釋為套件名.用例名否則解釋為套件名# a. 運行某套件的全部用例 ./tools/testing/kunit/kunit.py run kunit_executor_test # b. 運行特定用例套件前綴 ./tools/testing/kunit/kunit.py run example.example_simple_test # c. 通配符運行任何套件中名字含 64 的用例 ./tools/testing/kunit/kunit.py run *.*64* # d. 前綴通配例如只跑資源相關套件 ./tools/testing/kunit/kunit.py run kunit-resource*3.4 在 QEMU 上運行非 UML 架構大多數(shù)架構跑 QEMU 只需加--arch./tools/testing/kunit/kunit.py run --archx86_64--arch選擇一組預定義的架構配置集Kconfig QEMU 選項取值與 Kbuild 的ARCH變量一致um或不傳則走 UML--arch help列出全部合法值--cross_compile傳遞 Kbuild 的CROSS_COMPILE前綴例如交叉編譯 s390 時./tools/testing/kunit/kunit.py run \ --archs390 \ --cross_compiles390x-linux-gnu---qemu_config當--arch不支持某架構或需要自定義配置時編寫自己的QemuConfigPython 文件頂部from ..qemu_config import QemuArchParams并定義QEMU_ARCH變量用法示例./tools/testing/kunit/kunit.py run \ --timeout60 \ --jobs12 \ --qemu_config./tools/testing/kunit/qemu_configs/x86_64.py可參考 tools/testing/kunit/qemu_configs/x86_64.py 的實現(xiàn)。3.5 其余常用命令行參數(shù)./tools/testing/kunit/kunit.py run --help可查看全部選項--help放在命令前列出通用選項放在命令后列出該命令專有選項。run_wrapper 文檔 中最常用的包括參數(shù)說明--build_dir指定構建目錄內含.kunitconfig、.config與編譯產物默認.kunit--make_options追加make選項如--make_options W1打開編譯器警告--alltests啟用預定義選項集以構建盡可能多的測試清單見 all_tests.config若只想在依賴滿足時開啟全部測試改為在.kunitconfig中加CONFIG_KUNIT_ALL_TESTSy--kunitconfig.kunitconfig的文件路徑或所在目錄如lib/kunit/.kunitconfig--kconfig_add向.kunitconfig追加選項如--kconfig_add CONFIG_KASANy--qemu_args追加 QEMU 參數(shù)如-smp 8--kernel_args追加內核命令行參數(shù)可重復使用--run_isolated每個套件/用例單獨啟動一次內核便于排查非封閉性結果受此前用例影響的測試--raw_output輸出未格式化內核輸出all看全部默認或kunit只過濾 KUnit 輸出--json/--junit結果存為 JSON 或 JUnit XML打印到 stdout 或寫入指定文件--filter按測試屬性過濾如--filter speed!slow或--filter speedslow, moduleexample--filter_action設為skip時被過濾的測試在輸出中顯示為跳過--list_tests/--list_tests_attr/--list_suites列出將要運行的全部測試/屬性/套件另外倉庫自帶 bash 補全腳本source tools/testing/kunit/kunit-completion.sh即可啟用。3.6 解析原始結果測試輸出為 TAP 格式kunit_tool 默認解析后打印摘要加--raw_output可看原始 TAP。已有原始日志時可用parse命令單獨解析接受文件參數(shù)也可從 stdin 讀取# 從文件讀取 ./tools/testing/kunit/kunit.py parse /var/log/dmesg # 從 stdin 讀取 dmesg | ./tools/testing/kunit/kunit.py parse四、不使用 kunit_tool 手動運行當需要把測試集成進既有系統(tǒng)、使用其他/不支持的架構或配置、或在真實硬件上運行時KUnit 可以直接包含進任意內核手動讀取結果見 run_manual 文檔。注意KUnit 并非為生產系統(tǒng)設計也不應在生產環(huán)境啟用CONFIG_KUNIT——它會關閉 KASLR且測試可能以不適合生產的方式改變內核狀態(tài)。配置與運行流程使能CONFIG_KUNITmenuconfig中位于 Kernel Hacking / Kernel Testing and Coverage 下對應 lib/kunit/Kconfig 中的menuconfig KUNIT。各具體測試通常有以_KUNIT_TEST結尾的選項啟用KUNIT_ALL_TESTS可自動開啟所有依賴滿足的測試適合快速全量驗證測試可以編譯為模塊或內置內置的開機自動運行結果以 TAP 格式寫入dmesg可能夾雜其他日志行模塊式的在加載時運行例如modprobe example-test開機參數(shù)kunit.enable控制 KUnit 是否生效默認值 1由KUNIT_DEFAULT_ENABLED使能。為確保測試如期執(zhí)行請確認內核啟動時kunit.enable1若啟用CONFIG_KUNIT_DEBUGFS依賴DEBUG_FS默認 yKUnit 暴露 debugfs 接口掛載在/sys/kernel/debug/kunit讀取結果/sys/kernel/debug/kunit/test_suite/results只讀內容為 KTAP注意該文檔獨立于內核日志套件編號可能與 dmesg 不同開機后觸發(fā)內置測試echo any string /sys/kernel/debug/kunit/test_suite/run結果打印到內核日志。該功能對使用 init 數(shù)據(jù)kunit_test_init_section_suites()注冊的套件不可用——init 數(shù)據(jù)在內核啟動后可能被丟棄且不能并發(fā)運行測試會等待此前測試完成或失敗后再執(zhí)行。對測試作者而言這要求測試能正確地初始化/清理數(shù)據(jù)以支持二次運行。五、編寫你的第一個 KUnit 測試以下流程完整繼承自 Getting Started 指南在任意內核倉庫中按步驟操作即可。1. 先寫一段可測試的代碼。新建drivers/misc/example.hint misc_example_add(int left, int right);新建drivers/misc/example.c#include linux/errno.h #include example.h int misc_example_add(int left, int right) { return left right; }2. 接入構建系統(tǒng)。在drivers/misc/Kconfig增加config MISC_EXAMPLE bool My example在drivers/misc/Makefile增加obj-$(CONFIG_MISC_EXAMPLE) example.o3. 寫測試文件drivers/misc/example_test.c結構遵循 Arrange-Act-Assert#include kunit/test.h #include example.h /* Define the test cases. */ static void misc_example_add_test_basic(struct kunit *test) { KUNIT_EXPECT_EQ(test, 1, misc_example_add(1, 0)); KUNIT_EXPECT_EQ(test, 2, misc_example_add(1, 1)); KUNIT_EXPECT_EQ(test, 0, misc_example_add(-1, 1)); KUNIT_EXPECT_EQ(test, INT_MAX, misc_example_add(0, INT_MAX)); KUNIT_EXPECT_EQ(test, -1, misc_example_add(INT_MAX, INT_MIN)); } static void misc_example_test_failure(struct kunit *test) { KUNIT_FAIL(test, This test never passes.); } static struct kunit_case misc_example_test_cases[] { KUNIT_CASE(misc_example_add_test_basic), KUNIT_CASE(misc_example_test_failure), {} }; static struct kunit_suite misc_example_test_suite { .name misc-example, .test_cases misc_example_test_cases, }; kunit_test_suite(misc_example_test_suite); MODULE_LICENSE(GPL);4. 為測試注冊 Kconfig 選項drivers/misc/Kconfigconfig MISC_EXAMPLE_TEST tristate Test for my example if !KUNIT_ALL_TESTS depends on MISC_EXAMPLE KUNIT default KUNIT_ALL_TESTStristate表示測試支持編譯為模塊推薦若測試確實無法以模塊構建應改為bool且依賴KUNITy。5. 加入 Makefile 與.kunitconfigobj-$(CONFIG_MISC_EXAMPLE_TEST) example_test.oCONFIG_MISC_EXAMPLEy CONFIG_MISC_EXAMPLE_TESTy6. 運行并觀察輸出./tools/testing/kunit/kunit.py run預期看到一通過一失敗[16:08:57] [PASSED] misc-example:misc_example_add_test_basic [16:08:57] [FAILED] misc-example:misc_example_test_failure [16:08:57] EXPECTATION FAILED at drivers/misc/example-test.c:17 [16:08:57] This test never passes.至此你已完整走通了代碼 → Kconfig → Makefile → 測試 → 執(zhí)行的閉環(huán)?？蚣茏陨淼氖纠郎y試KUNIT_EXAMPLE_TEST見 lib/kunit/kunit-example-test.c其 Kconfig 定義在 lib/kunit/Kconfig也值得通讀它演示了套件 init/exit、參數(shù)化、資源 API 等更多特性。六、測試編寫進階usage 文檔核心模式Writing Tests 指南 覆蓋了從基礎到進階的編寫模式要點如下。6.1 期望與斷言的分工期望KUNIT_EXPECT_*失敗后測試繼續(xù)執(zhí)行收集盡可能多的失敗信息斷言KUNIT_ASSERT_*失敗則立即終止用例。典型用法分配內存這類失敗則無法繼續(xù)的場合用斷言a kunit_kmalloc_array(test, TEST_LEN, sizeof(*a), GFP_KERNEL); KUNIT_ASSERT_NOT_ERR_OR_NULL(test, a);一個用例應當短小、易懂、聚焦單一行為。例如對add函數(shù)把基本值、負數(shù)、邊界、溢出拆成add_test_basic/add_test_negative/add_test_max/add_test_overflow多個用例而不是塞進一個函數(shù)。警告不要在套件的exit()或資源的 free 函數(shù)里使用斷言——它們在測試拆除階段運行斷言會阻止后續(xù)清理代碼執(zhí)行可能導致內存泄漏。6.2 自定義錯誤消息與抑制 warning 回溯每個KUNIT_EXPECT/KUNIT_ASSERT都有_MSG變體接受格式串補充上下文/* Before. Not easy to tell why the test failed. */ KUNIT_EXPECT_EQ(test, strlen(some_str), 40); /* After. Now we see the offending string. */ KUNIT_EXPECT_EQ_MSG(test, strlen(some_str), 40, some_str%s, some_str);當同一期望在循環(huán)或輔助函數(shù)中被多次調用、行號不足以定位失敗時_MSG變體尤其有用。若想完全控制失敗消息可用KUNIT_FAIL(test, ...)。對于故意或順帶觸發(fā)WARN_ON*等警告回溯的測試可用任務級抑制避免干擾輸出static void some_test(struct kunit *test) { kunit_warning_suppress(test) { trigger_backtrace(); KUNIT_EXPECT_SUPPRESSED_WARNING_COUNT(test, 1); } }需要跨輔助函數(shù)保留句柄時改用直接函數(shù)形式kunit_start_suppress_warning()/kunit_end_suppress_warning()。注意計數(shù)檢查必須放在抑制塊內部。6.3 參數(shù)化測試從表驅動到生成器表驅動測試struct 數(shù)組 for 循環(huán)是常見起點KUnit 將其形式化為參數(shù)化測試框架用例對每個參數(shù)獨立運行一次每次運行有自己獨立的struct kunit參數(shù)運行上下文并共享一個父級struct kunit參數(shù)化測試上下文。三種參數(shù)提供方式數(shù)組參數(shù)宏對用例數(shù)組直接應用KUNIT_ARRAY_PARAM或KUNIT_ARRAY_PARAM_DESC后者指定用于用例描述的結構體成員struct sha1_test_case { const char *str; const char *sha1; }; static const struct sha1_test_case cases[] { { .str hello world, .sha1 2aae6c35c94fcfb415dbe95f408b9ce91ee846ed }, { .str hello world!, .sha1 430ce34d020724ed75a196dfc2ad67c77772d169 }, }; /* 生成 sha1_gen_params()遍歷 cases 并用 str 字段做描述 */ KUNIT_ARRAY_PARAM_DESC(sha1, cases, str); static void sha1_test(struct kunit *test) { char out[40]; struct sha1_test_case *test_param (struct sha1_test_case *)(test-param_value); sha1sum(test_param-str, out); KUNIT_EXPECT_STREQ_MSG(test, out, test_param-sha1, sha1sum(%s), test_param-str); } static struct kunit_case sha1_test_cases[] { KUNIT_CASE_PARAM(sha1_test, sha1_gen_params), {} };自定義生成器函數(shù)簽名const void* (*)(struct kunit *test, const void *prev, char *desc)KUnit 反復調用它直到返回NULL為止首次調用prev為NULL通過KUNIT_CASE_PARAM傳入。適合生成序列如 1、2、4、8… 的緩沖區(qū)大小。在 init 函數(shù)中運行時注冊參數(shù)數(shù)組面向動態(tài)構建的參數(shù)數(shù)組在param_init()簽名int (*)(struct kunit *test)中調用kunit_register_params_array(test, array, size, get_desc)注冊用例改用KUNIT_CASE_PARAM_WITH_INIT(test, kunit_array_gen_params, param_init, param_exit)。完整示例見 kunit-example-test.c。共享資源所有參數(shù)運行共享參數(shù)化測試上下文可用KUNIT_CASE_PARAM_WITH_INIT傳入param_init()/param_exit()各執(zhí)行一次。用例函數(shù)內訪問共享資源必須經由test-parent例如kunit_find_resource(test-parent, ...)也可以用test-parent-priv存放輕量級共享數(shù)據(jù)。注意suite-init()在每次參數(shù)運行前都會執(zhí)行其中分配的資源會在每次參數(shù)運行結束后清理——與param_init()中分配的一次性資源語義不同。6.4 內存管理與清理動作kunit_kzalloc替代kzallocKUnit 保證測試結束時自動釋放因此可以放心用KUNIT_ASSERT_*提前退出而無需記得kfreevoid example_test_allocation(struct kunit *test) { char *buffer kunit_kzalloc(test, 16, GFP_KERNEL); KUNIT_ASSERT_NOT_ERR_OR_NULL(test, buffer); KUNIT_ASSERT_STREQ(test, buffer, ); }kunit_add_action注冊延遲清理無返回值、帶單個void *上下文參數(shù)的函數(shù)測試退出無論正常還是斷言失敗時執(zhí)行類似 Python/Go 的 cleanup 或 C 析構。對只接受單個指針參數(shù)的解注冊函數(shù)可用KUNIT_DEFINE_ACTION_WRAPPER()宏生成包裝優(yōu)先于手工強轉因為強轉函數(shù)指針會破壞 CFIKUNIT_DEFINE_ACTION_WRAPPER(device_unregister, device_unregister_wrapper, struct device *); kunit_add_action(test, device_unregister_wrapper, dev);kunit_add_action_or_reset在無法延遲時立即執(zhí)行動作kunit_release_action可提前觸發(fā)kunit_remove_action可徹底取消。6.5 測試靜態(tài)函數(shù)與注入測試專用代碼條件導出符號在my_file.c中用VISIBLE_IF_KUNIT int do_interesting_thing()配合EXPORT_SYMBOL_IF_KUNIT(do_interesting_thing)頭文件含kunit/visibility.h僅在 KUnit 啟用時導出測試文件中用MODULE_IMPORT_NS(EXPORTED_FOR_KUNIT_TESTING)導入條件包含測試文件不推薦但可行在my_file.c末尾#ifdef CONFIG_MY_KUNIT_TEST時#include my_kunit_test.c注入測試鉤子在頭文件中#ifdef CONFIG_MY_KUNIT_TEST聲明測試實現(xiàn)、#else提供空實現(xiàn)訪問當前測試生產代碼中可通過kunit_get_current_test()kunit/test-bug.h基于task_struct的kunit_test字段獲取當前struct kunitKUnit 未啟用時返回NULL編譯為 no-op 或 static key 檢查無運行開銷。典型用途是實現(xiàn) fake 函數(shù)——在 fake 內部對入參做期望、返回預設值讓當前測試失敗kunit_fail_current_test(fmt, ...)同樣定義在kunit/test-bug.h無需引入kunit/test.h適合放在生產代碼的額外調試檢查路徑中。6.6 偽造類與假設備偽造類Fake Class內核中類即含函數(shù)指針的結構體形成實現(xiàn)者與使用者間的契約。測試調用類方法的代碼時用一個行為對調用者等價、但實現(xiàn)不同的 fake 類替換難以處理或緩慢的依賴——例如把 EEPROM 的讀寫實現(xiàn)為操作內部緩沖區(qū)struct fake_eeprom內嵌struct eeprom parent方法里用container_of還原自身指針再用它測試緩沖寫 EEPROM的邏輯斷言 flush 前底層內容不變、flush 后才寫入。完整的eeprom_buffer示例含 init/exit、test-priv上下文見 usage 文檔。假設備Fake Device測試與設備模型交互的代碼時KUnit 提供基于kunit_device掛在專用kunit_bus上的假設備支持 devres 托管資源。kunit_driver_create()創(chuàng)建托管 driverkunit_device_register()創(chuàng)建并注冊假設備kunit_device_register_with_driver()可指定非 KUnit 托管的 driver。托管的 driver/設備在測試結束時自動清理也可用kunit_device_unregister()提前清理。示例#include kunit/device.h static void test_my_device(struct kunit *test) { struct device *fake_device; const char *dev_managed_string; fake_device kunit_device_register(test, my_device); KUNIT_ASSERT_NOT_ERR_OR_NULL(test, fake_device); /* 把它傳給需要 device 的函數(shù) */ dev_managed_string devm_kstrdup(fake_device, Hello, World!); /* 測試結束時所有托管資源自動清理 */ }文檔建議優(yōu)先使用 KUnit 設備而非root_device_register()除非被測對象本來就是 platform device。6.7 跨架構測試原則優(yōu)先寫能在 UML 上運行的測試其次 QEMU 等免費軟件環(huán)境最后才是特定硬件。確實需要架構/硬件相關的測試時盡量讓多數(shù)用例不依賴物理硬件硬件不可用時跳過而不是禁用測試若硬件狀態(tài)無法復位可能一次只能跑一個用例。七、小結與延伸閱讀KUnit 的設計可以濃縮為三句話套件經鏈接段注冊、執(zhí)行器開機遍歷運行.kunit_test_suites executor.c用例在獨立線程上下文執(zhí)行以隔離故障try-catch.ckunit.py 把 config/build/exec/parse 自動化tools/testing/kunit/kunit.py。圍繞它繼續(xù)深入建議按以下路徑閱讀本倉庫文檔Getting Started首個測試的完整流程Running tests with kunit_tool全部命令行選項Run Tests without kunit_tool手動運行與 debugfs 接口KUnit Architecture框架內部結構Writing Tests本文第六節(jié)來源的完整模式集KUnit API 文檔斷言、資源、函數(shù)重定向mock、clk/of/platform device 等 API 細節(jié)Testing Style 與 FAQ、Running Tips風格規(guī)范、常見問題與調優(yōu)技巧?！久赓M下載鏈接】linuxLinux kernel source tree項目地址: https://gitcode.com/GitHub_Trending/li/linux創(chuàng)作聲明：本文部分內容由AI輔助生成（AIGC），僅供參考