測試風格和命名¶

為了使查詢、編寫和使用KUnit測試儘可能簡單，強烈建議按照以下準則命名和編寫它們。雖然可以編寫不遵循這些規則的KUnit測試，但它們可能會破壞某些工具，可能會與其他測試衝突，並且可能不會被測試系統自動執行。

建議僅在以下情況下偏離這些準則

將已知名稱的測試移植到KUnit。
編寫如果自動執行會導致嚴重問題的測試。例如，非確定性地產生誤報或誤報，或者花費很長時間才能執行。

子系統、套件和測試¶

為了使測試易於查詢，它們被分組到套件和子系統中。測試套件是測試核心相關區域的一組測試。子系統是一組測試套件，用於測試核心子系統或驅動程式的各個部分。

子系統¶

每個測試套件必須屬於一個子系統。子系統是一個或多個KUnit測試套件的集合，用於測試同一驅動程式或核心的一部分。測試子系統應匹配單個核心模組。如果被測試的程式碼無法編譯為模組，在許多情況下，子系統應對應於源樹中的目錄或MAINTAINERS檔案中的條目。如果不確定，請遵循類似區域中的測試設定的約定。

測試子系統應以被測試的程式碼命名，要麼以模組命名（如果可能），要麼以被測試的目錄或檔案命名。應命名測試子系統以避免必要的歧義。

如果測試子系統名稱有多個元件，則應以下劃線分隔。請勿直接在子系統名稱中包含“test”或“kunit”，除非我們實際上正在測試其他測試或kunit框架本身。例如，子系統可以稱為

ext4: 匹配模組和檔案系統名稱。
apparmor: 匹配模組名稱和LSM名稱。
kasan: 該工具的通用名稱，路徑mm/kasan的突出部分
snd_hda_codec_hdmi: 有幾個元件（snd，hda，codec，hdmi），用下劃線分隔。匹配模組名稱。

避免使用如下例所示的名稱

linear-ranges: 名稱應使用下劃線，而不是短劃線，來分隔單詞。優先使用linear_ranges。
qos-kunit-test: 該名稱應使用下劃線，並且不應以“kunit-test”作為字尾。 qos作為子系統名稱也很模糊，因為核心的幾個部分都有一個qos子系統。 power_qos會是一個更好的名字。
pc_parallel_port: 對應的模組名稱是parport_pc，所以這個子系統也應該命名為parport_pc。

注意

KUnit API和工具沒有明確地瞭解子系統。它們是一種對測試套件進行分類和命名模組的方式，為人類提供了一種簡單、一致的方式來查詢和執行測試。將來可能會發生變化。

套件¶

KUnit測試被分組到測試套件中，這些套件涵蓋了被測的特定功能領域。測試套件可以具有共享的初始化和關閉程式碼，這些程式碼針對套件中的所有測試執行。並非所有子系統都需要拆分為多個測試套件（例如，簡單的驅動程式）。

測試套件以它們所屬的子系統命名。如果子系統包含多個套件，則應將被測的特定區域附加到子系統名稱，以下劃線分隔。

如果在子系統中存在多種型別的測試使用KUnit（例如，單元測試和整合測試），則應將它們放入單獨的套件中，並將測試型別作為套件名稱中的最後一個元素。除非這些測試實際存在，否則請避免在套件名稱中使用_test，_unittest或類似內容。

完整的測試套件名稱（包括子系統名稱）應指定為kunit_suite結構的.name成員，並構成模組名稱的基礎。例如，測試套件可以包括

ext4_inode: 是ext4子系統的一部分，用於測試inode區域。
kunit_try_catch: 是kunit實現本身的一部分，用於測試try_catch區域。
apparmor_property_entry: 是apparmor子系統的一部分，用於測試property_entry區域。
kasan: kasan子系統只有一個套件，因此套件名稱與子系統名稱相同。

避免使用名稱，例如

ext4_ext4_inode: 沒有理由兩次宣告子系統。
property_entry: 沒有子系統名稱，套件名稱不明確。
kasan_integration_test: 因為在kasan子系統中只有一個套件，所以該套件應僅稱為kasan。不要冗餘地新增integration_test。它應該是一個單獨的測試套件。例如，如果添加了單元測試，則該套件可以命名為kasan_unittest或類似名稱。

測試用例¶

單個測試包括一個測試受約束的程式碼路徑，屬性或功能的單個函式。在測試輸出中，單個測試的結果將顯示為套件結果的子測試。

測試應以它們正在測試的內容命名。這通常是被測函式的名稱，並描述被測的輸入或程式碼路徑。由於測試是C函式，因此應按照核心編碼風格命名和編寫它們。

注意

由於測試本身就是函式，因此它們的名稱不能與核心中的其他C識別符號衝突。這可能需要一些創造性的命名。最好使您的測試函式為static，以避免汙染全域性名稱空間。

示例測試名稱包括

unpack_u32_with_null_name: 當傳入NULL名稱時，測試unpack_u32函式。
test_list_splice: 測試list_splice宏。它具有字首test_，以避免與宏本身發生名稱衝突。

如果需要在其測試套件的上下文之外引用測試，則測試的完全限定名稱應為套件名稱，後跟測試名稱，以冒號分隔（即suite:test）。

測試Kconfig條目¶

每個測試套件都應繫結到一個Kconfig條目。

此Kconfig條目必須

命名為CONFIG_<name>_KUNIT_TEST：其中<name>是測試套件的名稱。
與被測驅動程式/子系統的配置條目一起列出，或在[核心Hacking]->[核心測試和覆蓋率]下
依賴於CONFIG_KUNIT。
僅當未啟用CONFIG_KUNIT_ALL_TESTS時才可見。
具有CONFIG_KUNIT_ALL_TESTS的預設值。
在幫助文字中簡要描述KUnit。

如果我們無法滿足上述條件（例如，測試無法構建為模組），則測試的Kconfig條目應為三態。

例如，Kconfig條目可能如下所示

config FOO_KUNIT_TEST
        tristate "KUnit test for foo" if !KUNIT_ALL_TESTS
        depends on KUNIT
        default KUNIT_ALL_TESTS
        help
          This builds unit tests for foo.

          For more information on KUnit and unit tests in general,
          please refer to the KUnit documentation in Documentation/dev-tools/kunit/.

          If unsure, say N.

測試檔案和模組名稱¶

KUnit測試通常編譯為單獨的模組。為了避免與常規模組衝突，KUnit模組應以測試套件命名，後跟_kunit（例如，如果“foobar”是核心模組，則“foobar_kunit”是KUnit測試模組）。

測試原始檔（無論是編譯為單獨的模組還是另一個原始檔中的#include），最好儲存在tests/子目錄中，以免與其他原始檔衝突（例如，用於製表符補全）。

請注意，在某些現有測試中也使用了_test字尾。優先使用_kunit字尾，因為它使KUnit測試和非KUnit測試之間的區別更加清晰。

因此，對於常見情況，請將包含測試套件的檔案命名為tests/<suite>_kunit.c。 tests目錄應與被測程式碼位於同一級別。例如，lib/string.c的測試位於lib/tests/string_kunit.c中。

如果套件名稱包含測試的父目錄的某些或全部名稱，則修改原始檔名以減少冗餘可能是有意義的。例如，foo_firmware套件可能位於foo/tests/firmware_kunit.c檔案中。

Linux核心

目錄

本頁