blob: 0f778c3643617d4078b8289ba1b9241374183928 [file] [log] [blame]
Release Notes
This page briefly summarizes the KUnit changes in each Linux release.
For more specific documentation on KUnit features, see the in-kernel
- KUnit introduced, including all the basic functionality.
- ``kunitconfig`` was renamed to ``.kunitconfig`` later in in 5.5 (`commit
- KUnit tests can be built as modules, `docs
- switched to using ``.kunit/`` as the default build dir (and
``.kunitconfig`` => ``.kunit/.kunitconfig``).
- ``CONFIG_KUNIT_DEBUGFS`` to expose per-suite test results in
``/sys/kernel/debug/kunit/<suite>/results``, `docs
- ```` now supports separate ``config/build/exec/parse`` commands in
addition to ``run``.
- You can use these if you don't want to let `` run`` do everything
for you, e.g. if you want to run manually but parse the results using
- ``CONFIG_KUNIT_ALL_TESTS`` introduced
- This is just a convention. New tests should use it like so:
.. code-block:: none
tristate "KUnit test for foo" if !KUNIT_ALL_TESTS
depends on KUNIT
This builds unit tests for foo.
See `the upstream documentation
for the authoritative source on how to write Kconfig entries.
- Named resources: tests can store and retrieve data via string keys.
- This is a power feature intended to be a cleaner alternative to using
global variables in tests.
- See `test_kasan.c
<>`__ for an
example that uses ``"kasan_data"``.
- KASAN violations cause the current KUnit test case to be marked FAILED.
- Note: KASAN doesn't currently work on UML.
- Parameterized testing: see the `docs
- You can pass in a path to a kunitconfig file instead of using
``.kunit/.kunitconfig``, e.g.
.. code-block:: shell
$ ./tools/testing/kunit/ run --kunitconfig=fs/ext4/.kunitconfig
- You can tell ```` to run a subset of built suites by passing in a
glob argument, e.g.
.. code-block:: shell
# Only run "list" suites
$ ./tools/testing/kunit/ run '*list*'
- Can call ``kunit_fail_current_test()`` from anywhere to fail the current KUnit test (e.g. if an invariant is broken, a UBSAN violation is detected, etc.)
- You can pass a directory ``--kunitconfig`` and it'll implicitly append
``.kunitconfig``, e.g. `` run --kunitconfig=lib/kunit``.
- ```` can run tests on non-UML architectures (using QEMU), `docs
- It's now possible to generate code coverage reports when using UML, `docs
- Tests can call ``kunit_skip()`` to bail out and mark a test as "SKIPPED"
instead of "PASSED" or "FAILED"
- UBSAN violations cause the current KUnit test case to be marked FAILED.
- Can pass kernel commandline parameters from ```` via
- KUnit prints a summary per suite of how many test cases passed/failed to
dmesg, e.g.
.. code-block:: shell
# property-entry: pass:7 fail:0 skip:0 total:7
5.16 (tentative)
- You can filter on test names now in addition to suite names, e.g.
.. code-block:: shell
# Only run tests that contain "foo"
$ ./tools/testing/kunit/ run '*.*foo*'
# Only run tests in "mysuite" that contain "foo"
$ ./tools/testing/kunit/ run 'mysuite.*foo*'
- You can ask ```` to run each suite/test by itself. This can be useful
to track down issues due to non-hermetic tests
.. code-block:: shell
$ ./tools/testing/kunit/ run --run_isolated=suite
$ ./tools/testing/kunit/ run --run_isolated=test
- ````'s parsing logic was largely rewrriten, so the output looks
slightly different
- Parsed output is also now mostly printed out in real time.
- ```` with ``--raw_output`` will print output in real time.