1 .. SPDX-License-Identifier: GPL-2.0 1 .. SPDX-License-Identifier: GPL-2.0
2 2
3 ================================= !! 3 =========================================
4 KUnit - Linux Kernel Unit Testing !! 4 KUnit - Unit Testing for the Linux Kernel
5 ================================= !! 5 =========================================
6 6
7 .. toctree:: 7 .. toctree::
8 :maxdepth: 2 8 :maxdepth: 2
9 :caption: Contents: <<
10 9
11 start 10 start
12 architecture <<
13 run_wrapper <<
14 run_manual <<
15 usage 11 usage
>> 12 kunit-tool
16 api/index 13 api/index
17 style <<
18 faq 14 faq
19 running_tips <<
20 15
21 This section details the kernel unit testing f !! 16 What is KUnit?
>> 17 ==============
22 18
23 Introduction !! 19 KUnit is a lightweight unit testing and mocking framework for the Linux kernel.
24 ============ <<
25 20
26 KUnit (Kernel unit testing framework) provides !! 21 KUnit is heavily inspired by JUnit, Python's unittest.mock, and
27 unit tests within the Linux kernel. Using KUni !! 22 Googletest/Googlemock for C++. KUnit provides facilities for defining unit test
28 of test cases called test suites. The tests ei !! 23 cases, grouping related test cases into test suites, providing common
29 if built-in, or load as a module. KUnit automa !! 24 infrastructure for running tests, and much more.
30 failed test cases in the kernel log. The test !! 25
31 :doc:`KTAP (Kernel - Test Anything Protocol) f !! 26 KUnit consists of a kernel component, which provides a set of macros for easily
32 It is inspired by JUnit, Python’s unittest.m !! 27 writing unit tests. Tests written against KUnit will run on kernel boot if
33 (C++ unit testing framework). !! 28 built-in, or when loaded if built as a module. These tests write out results to
34 !! 29 the kernel log in `TAP <https://testanything.org/>`_ format.
35 KUnit tests are part of the kernel, written in !! 30
36 language, and test parts of the Kernel impleme !! 31 To make running these tests (and reading the results) easier, KUnit offers
37 language function). Excluding build time, from !! 32 :doc:`kunit_tool <kunit-tool>`, which builds a `User Mode Linux
38 completion, KUnit can run around 100 tests in !! 33 <http://user-mode-linux.sourceforge.net>`_ kernel, runs it, and parses the test
39 KUnit can test any kernel component, for examp !! 34 results. This provides a quick way of running KUnit tests during development,
40 calls, memory management, device drivers and s !! 35 without requiring a virtual machine or separate hardware.
41 !! 36
42 KUnit follows the white-box testing approach. !! 37 Get started now: :doc:`start`
43 internal system functionality. KUnit runs in k !! 38
44 restricted to things exposed to user-space. !! 39 Why KUnit?
45 !! 40 ==========
46 In addition, KUnit has kunit_tool, a script (` !! 41
47 that configures the Linux kernel, runs KUnit t !! 42 A unit test is supposed to test a single unit of code in isolation, hence the
48 (:doc:`User Mode Linux </virt/uml/user_mode_li !! 43 name. A unit test should be the finest granularity of testing and as such should
49 parses the test results and !! 44 allow all possible code paths to be tested in the code under test; this is only
50 displays them in a user friendly manner. !! 45 possible if the code under test is very small and does not have any external
51 !! 46 dependencies outside of the test's control like hardware.
52 Features !! 47
53 -------- !! 48 KUnit provides a common framework for unit tests within the kernel.
54 !! 49
55 - Provides a framework for writing unit tests. !! 50 KUnit tests can be run on most architectures, and most tests are architecture
56 - Runs tests on any kernel architecture. !! 51 independent. All built-in KUnit tests run on kernel startup. Alternatively,
57 - Runs a test in milliseconds. !! 52 KUnit and KUnit tests can be built as modules and tests will run when the test
58 !! 53 module is loaded.
59 Prerequisites !! 54
60 ------------- !! 55 .. note::
61 !! 56
62 - Any Linux kernel compatible hardware. !! 57 KUnit can also run tests without needing a virtual machine or actual
63 - For Kernel under test, Linux kernel version !! 58 hardware under User Mode Linux. User Mode Linux is a Linux architecture,
64 !! 59 like ARM or x86, which compiles the kernel as a Linux executable. KUnit
65 Unit Testing !! 60 can be used with UML either by building with ``ARCH=um`` (like any other
66 ============ !! 61 architecture), or by using :doc:`kunit_tool <kunit-tool>`.
67 !! 62
68 A unit test tests a single unit of code in iso !! 63 KUnit is fast. Excluding build time, from invocation to completion KUnit can run
69 granularity of testing and allows all possible !! 64 several dozen tests in only 10 to 20 seconds; this might not sound like a big
70 code under test. This is possible if the code !! 65 deal to some people, but having such fast and easy to run tests fundamentally
71 have any external dependencies outside of the !! 66 changes the way you go about testing and even writing code in the first place.
72 !! 67 Linus himself said in his `git talk at Google
73 !! 68 <https://gist.github.com/lorn/1272686/revisions#diff-53c65572127855f1b003db4064a94573R874>`_:
74 Write Unit Tests !! 69
75 ---------------- !! 70 "... a lot of people seem to think that performance is about doing the
76 !! 71 same thing, just doing it faster, and that is not true. That is not what
77 To write good unit tests, there is a simple bu !! 72 performance is all about. If you can do something really fast, really
78 Arrange-Act-Assert. This is a great way to str !! 73 well, people will start using it differently."
79 defines an order of operations. !! 74
80 !! 75 In this context Linus was talking about branching and merging,
81 - Arrange inputs and targets: At the start of !! 76 but this point also applies to testing. If your tests are slow, unreliable, are
82 that allows a function to work. Example: ini !! 77 difficult to write, and require a special setup or special hardware to run,
83 object. !! 78 then you wait a lot longer to write tests, and you wait a lot longer to run
84 - Act on the target behavior: Call your functi !! 79 tests; this means that tests are likely to break, unlikely to test a lot of
85 - Assert expected outcome: Verify that the res !! 80 things, and are unlikely to be rerun once they pass. If your tests are really
86 expected. !! 81 fast, you run them all the time, every time you make a change, and every time
87 !! 82 someone sends you some code. Why trust that someone ran all their tests
88 Unit Testing Advantages !! 83 correctly on every change when you can just run them yourself in less time than
89 ----------------------- !! 84 it takes to read their test log?
90 <<
91 - Increases testing speed and development in t <<
92 - Detects bugs at initial stage and therefore <<
93 compared to acceptance testing. <<
94 - Improves code quality. <<
95 - Encourages writing testable code. <<
96 <<
97 Read also :ref:`kinds-of-tests`. <<
98 85
99 How do I use it? 86 How do I use it?
100 ================ 87 ================
101 88
102 You can find a step-by-step guide to writing a !! 89 * :doc:`start` - for new users of KUnit
103 Documentation/dev-tools/kunit/start.rst !! 90 * :doc:`usage` - for a more detailed explanation of KUnit features
104 !! 91 * :doc:`api/index` - for the list of KUnit APIs used for testing
105 Alternatively, feel free to look through the r !! 92 * :doc:`kunit-tool` - for more information on the kunit_tool helper script
106 or to experiment with tools/testing/kunit/kuni !! 93 * :doc:`faq` - for answers to some common questions about KUnit
107 lib/kunit/kunit-example-test.c <<
108 <<
109 Happy testing! <<
Linux® is a registered trademark of Linus Torvalds in the United States and other countries.
TOMOYO® is a registered trademark of NTT DATA CORPORATION.