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