1.. SPDX-License-Identifier: GPL-2.0
2
3============================
4Run Tests without kunit_tool
5============================
6
7If we do not want to use kunit_tool (For example: we want to integrate
8with other systems, or run tests on real hardware), we can
9include KUnit in any kernel, read out results, and parse manually.
10
11.. note:: KUnit is not designed for use in a production system. It is
12          possible that tests may reduce the stability or security of
13          the system.
14
15Configure the Kernel
16====================
17
18KUnit tests can run without kunit_tool. This can be useful, if:
19
20- We have an existing kernel configuration to test.
21- Need to run on real hardware (or using an emulator/VM kunit_tool
22  does not support).
23- Wish to integrate with some existing testing systems.
24
25KUnit is configured with the ``CONFIG_KUNIT`` option, and individual
26tests can also be built by enabling their config options in our
27``.config``. KUnit tests usually (but don't always) have config options
28ending in ``_KUNIT_TEST``. Most tests can either be built as a module,
29or be built into the kernel.
30
31.. note ::
32
33	We can enable the ``KUNIT_ALL_TESTS`` config option to
34	automatically enable all tests with satisfied dependencies. This is
35	a good way of quickly testing everything applicable to the current
36	config.
37
38Once we have built our kernel (and/or modules), it is simple to run
39the tests. If the tests are built-in, they will run automatically on the
40kernel boot. The results will be written to the kernel log (``dmesg``)
41in TAP format.
42
43If the tests are built as modules, they will run when the module is
44loaded.
45
46.. code-block :: bash
47
48	# modprobe example-test
49
50The results will appear in TAP format in ``dmesg``.
51
52.. note ::
53
54	If ``CONFIG_KUNIT_DEBUGFS`` is enabled, KUnit test results will
55	be accessible from the ``debugfs`` filesystem (if mounted).
56	They will be in ``/sys/kernel/debug/kunit/<test_suite>/results``, in
57	TAP format.
58