4
4
Getting Started
5
5
===============
6
6
7
- Installing dependencies
7
+ Installing Dependencies
8
8
=======================
9
- KUnit has the same dependencies as the Linux kernel. As long as you can build
10
- the kernel, you can run KUnit.
9
+ KUnit has the same dependencies as the Linux kernel. As long as you can
10
+ build the kernel, you can run KUnit.
11
11
12
- Running tests with the KUnit Wrapper
13
- ====================================
14
- Included with KUnit is a simple Python wrapper which runs tests under User Mode
15
- Linux, and formats the test results.
16
-
17
- The wrapper can be run with:
12
+ Running tests with kunit_tool
13
+ =============================
14
+ kunit_tool is a Python script, which configures and builds a kernel, runs
15
+ tests, and formats the test results. From the kernel repository, you
16
+ can run kunit_tool:
18
17
19
18
.. code-block :: bash
20
19
21
20
./tools/testing/kunit/kunit.py run
22
21
23
- For more information on this wrapper (also called kunit_tool) check out the
24
- Documentation/dev-tools/kunit/kunit-tool.rst page.
22
+ For more information on this wrapper, see:
23
+ Documentation/dev-tools/kunit/kunit-tool.rst.
24
+
25
+ Creating a ``.kunitconfig ``
26
+ ---------------------------
27
+
28
+ By default, kunit_tool runs a selection of tests. However, you can specify which
29
+ unit tests to run by creating a ``.kunitconfig `` file with kernel config options
30
+ that enable only a specific set of tests and their dependencies.
31
+ The ``.kunitconfig `` file contains a list of kconfig options which are required
32
+ to run the desired targets. The ``.kunitconfig `` also contains any other test
33
+ specific config options, such as test dependencies. For example: the
34
+ ``FAT_FS `` tests - ``FAT_KUNIT_TEST ``, depends on
35
+ ``FAT_FS ``. ``FAT_FS `` can be enabled by selecting either ``MSDOS_FS ``
36
+ or ``VFAT_FS ``. To run ``FAT_KUNIT_TEST ``, the ``.kunitconfig `` has:
25
37
26
- Creating a .kunitconfig
27
- -----------------------
28
- If you want to run a specific set of tests (rather than those listed in the
29
- KUnit defconfig), you can provide Kconfig options in the ``.kunitconfig `` file.
30
- This file essentially contains the regular Kernel config, with the specific
31
- test targets as well. The ``.kunitconfig `` should also contain any other config
32
- options required by the tests.
38
+ .. code-block :: none
39
+
40
+ CONFIG_KUNIT=y
41
+ CONFIG_MSDOS_FS=y
42
+ CONFIG_FAT_KUNIT_TEST=y
33
43
34
- A good starting point for a ``.kunitconfig `` is the KUnit defconfig:
44
+ 1. A good starting point for the ``.kunitconfig ``, is the KUnit default
45
+ config. Run the command:
35
46
36
47
.. code-block :: bash
37
48
38
49
cd $PATH_TO_LINUX_REPO
39
50
cp tools/testing/kunit/configs/default.config .kunitconfig
40
51
41
- You can then add any other Kconfig options you wish, e.g.:
52
+ .. note ::
53
+ You may want to remove CONFIG_KUNIT_ALL_TESTS from the ``.kunitconfig`` as
54
+ it will enable a number of additional tests that you may not want.
55
+
56
+ 2. You can then add any other Kconfig options, for example:
42
57
43
58
.. code-block :: none
44
59
45
60
CONFIG_LIST_KUNIT_TEST=y
46
61
47
- :doc: `kunit_tool <kunit-tool >` will ensure that all config options set in
48
- ``.kunitconfig `` are set in the kernel ``.config `` before running the tests.
49
- It'll warn you if you haven't included the dependencies of the options you're
50
- using.
62
+ Before running the tests, kunit_tool ensures that all config options
63
+ set in ``.kunitconfig `` are set in the kernel ``.config ``. It will warn
64
+ you if you have not included dependencies for the options used.
51
65
52
- .. note ::
53
- Note that removing something from the ``.kunitconfig `` will not trigger a
54
- rebuild of the ``.config `` file: the configuration is only updated if the
55
- ``.kunitconfig `` is not a subset of ``.config ``. This means that you can use
56
- other tools (such as make menuconfig) to adjust other config options.
66
+ .. note ::
67
+ The configuration is only updated if the ``.kunitconfig`` is not a
68
+ subset of ``.config``. You can use tools (for example:
69
+ make menuconfig) to adjust other config options.
57
70
58
-
59
- Running the tests (KUnit Wrapper)
60
- ---------------------------------
61
-
62
- To make sure that everything is set up correctly, simply invoke the Python
63
- wrapper from your kernel repo:
71
+ Running Tests (KUnit Wrapper)
72
+ -----------------------------
73
+ 1. To make sure that everything is set up correctly, invoke the Python
74
+ wrapper from your kernel repository:
64
75
65
76
.. code-block :: bash
66
77
67
78
./tools/testing/kunit/kunit.py run
68
79
69
- .. note ::
70
- You may want to run ``make mrproper `` first.
71
-
72
80
If everything worked correctly, you should see the following:
73
81
74
- .. code-block :: bash
82
+ .. code-block ::
75
83
76
84
Generating .config ...
77
85
Building KUnit Kernel ...
78
86
Starting KUnit Kernel ...
79
87
80
- followed by a list of tests that are run. All of them should be passing .
88
+ The tests will pass or fail .
81
89
82
- .. note ::
83
- Because it is building a lot of sources for the first time, the
84
- ``Building KUnit kernel `` step may take a while.
90
+ .. note ::
91
+ Because it is building a lot of sources for the first time, the
92
+ ``Building KUnit kernel`` may take a while.
85
93
86
- Running tests without the KUnit Wrapper
94
+ Running Tests without the KUnit Wrapper
87
95
=======================================
88
-
89
- If you'd rather not use the KUnit Wrapper (if, for example, you need to
90
- integrate with other systems, or use an architecture other than UML ), KUnit can
91
- be included in any kernel, and the results read out and parsed manually.
92
-
93
- .. note ::
94
- KUnit is not designed for use in a production system, and it's possible that
95
- tests may reduce the stability or security of the system.
96
-
97
-
98
-
99
- Configuring the kernel
96
+ If you do not want to use the KUnit Wrapper (for example: you want code
97
+ under test to integrate with other systems, or use a different/
98
+ unsupported architecture or configuration ), KUnit can be included in
99
+ any kernel, and the results are read out and parsed manually.
100
+
101
+ .. note ::
102
+ ``CONFIG_KUNIT`` should not be enabled in a production environment.
103
+ Enabling KUnit disables Kernel Address-Space Layout Randomization
104
+ (KASLR), and tests may affect the state of the kernel in ways not
105
+ suitable for production.
106
+
107
+ Configuring the Kernel
100
108
----------------------
109
+ To enable KUnit itself, you need to enable the ``CONFIG_KUNIT `` Kconfig
110
+ option (under Kernel Hacking/Kernel Testing and Coverage in
111
+ ``menuconfig ``). From there, you can enable any KUnit tests. They
112
+ usually have config options ending in ``_KUNIT_TEST ``.
101
113
102
- In order to enable KUnit itself, you simply need to enable the ``CONFIG_KUNIT ``
103
- Kconfig option (it's under Kernel Hacking/Kernel Testing and Coverage in
104
- menuconfig). From there, you can enable any KUnit tests you want: they usually
105
- have config options ending in ``_KUNIT_TEST ``.
106
-
107
- KUnit and KUnit tests can be compiled as modules: in this case the tests in a
108
- module will be run when the module is loaded.
114
+ KUnit and KUnit tests can be compiled as modules. The tests in a module
115
+ will run when the module is loaded.
109
116
110
-
111
- Running the tests (w/o KUnit Wrapper)
117
+ Running Tests (without KUnit Wrapper)
112
118
-------------------------------------
119
+ Build and run your kernel. In the kernel log, the test output is printed
120
+ out in the TAP format. This will only happen by default if KUnit/tests
121
+ are built-in. Otherwise the module will need to be loaded.
113
122
114
- Build and run your kernel as usual. Test output will be written to the kernel
115
- log in `TAP <https://testanything.org/ >`_ format.
116
-
117
- .. note ::
118
- It's possible that there will be other lines and/or data interspersed in the
119
- TAP output.
120
-
123
+ .. note ::
124
+ Some lines and/or data may get interspersed in the TAP output.
121
125
122
- Writing your first test
126
+ Writing Your First Test
123
127
=======================
128
+ In your kernel repository, let's add some code that we can test.
124
129
125
- In your kernel repo let's add some code that we can test. Create a file
126
- ``drivers/misc/example.h `` with the contents:
130
+ 1. Create a file ``drivers/misc/example.h ``, which includes:
127
131
128
132
.. code-block :: c
129
133
130
134
int misc_example_add(int left, int right);
131
135
132
- create a file ``drivers/misc/example.c ``:
136
+ 2. Create a file ``drivers/misc/example.c ``, which includes :
133
137
134
138
.. code-block :: c
135
139
@@ -142,21 +146,22 @@ create a file ``drivers/misc/example.c``:
142
146
return left + right;
143
147
}
144
148
145
- Now add the following lines to ``drivers/misc/Kconfig ``:
149
+ 3. Add the following lines to ``drivers/misc/Kconfig ``:
146
150
147
151
.. code-block :: kconfig
148
152
149
153
config MISC_EXAMPLE
150
154
bool "My example"
151
155
152
- and the following lines to ``drivers/misc/Makefile ``:
156
+ 4. Add the following lines to ``drivers/misc/Makefile ``:
153
157
154
158
.. code-block :: make
155
159
156
160
obj-$(CONFIG_MISC_EXAMPLE) += example.o
157
161
158
- Now we are ready to write the test. The test will be in
159
- ``drivers/misc/example-test.c ``:
162
+ Now we are ready to write the test cases.
163
+
164
+ 1. Add the below test case in ``drivers/misc/example_test.c ``:
160
165
161
166
.. code-block :: c
162
167
@@ -191,7 +196,7 @@ Now we are ready to write the test. The test will be in
191
196
};
192
197
kunit_test_suite(misc_example_test_suite);
193
198
194
- Now add the following to ``drivers/misc/Kconfig ``:
199
+ 2. Add the following lines to ``drivers/misc/Kconfig ``:
195
200
196
201
.. code-block :: kconfig
197
202
@@ -200,20 +205,20 @@ Now add the following to ``drivers/misc/Kconfig``:
200
205
depends on MISC_EXAMPLE && KUNIT=y
201
206
default KUNIT_ALL_TESTS
202
207
203
- and the following to ``drivers/misc/Makefile ``:
208
+ 3. Add the following lines to ``drivers/misc/Makefile ``:
204
209
205
210
.. code-block :: make
206
211
207
- obj-$(CONFIG_MISC_EXAMPLE_TEST) += example-test .o
212
+ obj-$(CONFIG_MISC_EXAMPLE_TEST) += example_test .o
208
213
209
- Now add it to your ``.kunitconfig ``:
214
+ 4. Add the following lines to ``.kunitconfig ``:
210
215
211
216
.. code-block :: none
212
217
213
218
CONFIG_MISC_EXAMPLE=y
214
219
CONFIG_MISC_EXAMPLE_TEST=y
215
220
216
- Now you can run the test:
221
+ 5. Run the test:
217
222
218
223
.. code-block :: bash
219
224
@@ -227,16 +232,20 @@ You should see the following failure:
227
232
[16:08:57] [PASSED] misc-example:misc_example_add_test_basic
228
233
[16:08:57] [FAILED] misc-example:misc_example_test_failure
229
234
[16:08:57] EXPECTATION FAILED at drivers/misc/example-test.c:17
230
- [16:08:57] This test never passes.
235
+ [16:08:57] This test never passes.
231
236
...
232
237
233
- Congrats! You just wrote your first KUnit test!
238
+ Congrats! You just wrote your first KUnit test.
234
239
235
240
Next Steps
236
241
==========
237
- * Check out the Documentation/dev-tools/kunit/tips.rst page for tips on
238
- writing idiomatic KUnit tests.
239
- * Check out the :doc: `running_tips ` page for tips on
240
- how to make running KUnit tests easier.
241
- * Optional: see the :doc: `usage ` page for a more
242
- in-depth explanation of KUnit.
242
+
243
+ * Documentation/dev-tools/kunit/usage.rst - KUnit features.
244
+ * Documentation/dev-tools/kunit/tips.rst - best practices with
245
+ examples.
246
+ * Documentation/dev-tools/kunit/api/index.rst - KUnit APIs
247
+ used for testing.
248
+ * Documentation/dev-tools/kunit/kunit-tool.rst - kunit_tool helper
249
+ script.
250
+ * Documentation/dev-tools/kunit/faq.rst - KUnit common questions and
251
+ answers.
0 commit comments