sphinx.addnodesdocument)}( rawsourcechildren]( translations LanguagesNode)}(hhh](h pending_xref)}(hhh]docutils.nodesTextChinese (Simplified)}parenthsba attributes}(ids]classes]names]dupnames]backrefs] refdomainstdreftypedoc reftarget0/translations/zh_CN/dev-tools/kunit/running_tipsmodnameN classnameN refexplicitutagnamehhh ubh)}(hhh]hChinese (Traditional)}hh2sbah}(h]h ]h"]h$]h&] refdomainh)reftypeh+ reftarget0/translations/zh_TW/dev-tools/kunit/running_tipsmodnameN classnameN refexplicituh1hhh ubh)}(hhh]hItalian}hhFsbah}(h]h ]h"]h$]h&] refdomainh)reftypeh+ reftarget0/translations/it_IT/dev-tools/kunit/running_tipsmodnameN classnameN refexplicituh1hhh ubh)}(hhh]hJapanese}hhZsbah}(h]h ]h"]h$]h&] refdomainh)reftypeh+ reftarget0/translations/ja_JP/dev-tools/kunit/running_tipsmodnameN classnameN refexplicituh1hhh ubh)}(hhh]hKorean}hhnsbah}(h]h ]h"]h$]h&] refdomainh)reftypeh+ reftarget0/translations/ko_KR/dev-tools/kunit/running_tipsmodnameN classnameN refexplicituh1hhh ubh)}(hhh]hPortuguese (Brazilian)}hhsbah}(h]h ]h"]h$]h&] refdomainh)reftypeh+ reftarget0/translations/pt_BR/dev-tools/kunit/running_tipsmodnameN classnameN refexplicituh1hhh ubh)}(hhh]hSpanish}hhsbah}(h]h ]h"]h$]h&] refdomainh)reftypeh+ reftarget0/translations/sp_SP/dev-tools/kunit/running_tipsmodnameN classnameN refexplicituh1hhh ubeh}(h]h ]h"]h$]h&]current_languageEnglishuh1h hh _documenthsourceNlineNubhcomment)}(h SPDX-License-Identifier: GPL-2.0h]h SPDX-License-Identifier: GPL-2.0}hhsbah}(h]h ]h"]h$]h&] xml:spacepreserveuh1hhhhhhJ/var/lib/git/docbuild/linux/Documentation/dev-tools/kunit/running_tips.rsthKubhsection)}(hhh](htitle)}(hTips For Running KUnit Testsh]hTips For Running KUnit Tests}(hhhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhhhhhKubh)}(hhh](h)}(h%Using ``kunit.py run`` ("kunit tool")h](hUsing }(hhhhhNhNubhliteral)}(h``kunit.py run``h]h kunit.py run}(hhhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhubh (“kunit tool”)}(hhhhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhhhhhKubh)}(hhh](h)}(hRunning from any directoryh]hRunning from any directory}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjhhhhhK ubh paragraph)}(h/It can be handy to create a bash function like:h]h/It can be handy to create a bash function like:}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1jhhhK hjhhubh literal_block)}(hofunction run_kunit() { ( cd "$(git rev-parse --show-toplevel)" && ./tools/testing/kunit/kunit.py run "$@" ) }h]hofunction run_kunit() { ( cd "$(git rev-parse --show-toplevel)" && ./tools/testing/kunit/kunit.py run "$@" ) }}hj%sbah}(h]h ]h"]h$]h&]hhƌforcelanguagebashhighlight_args}uh1j#hhhKhjhhubhnote)}(hEarly versions of ``kunit.py`` (before 5.6) didn't work unless run from the kernel root, hence the use of a subshell and ``cd``.h]j)}(hEarly versions of ``kunit.py`` (before 5.6) didn't work unless run from the kernel root, hence the use of a subshell and ``cd``.h](hEarly versions of }(hj>hhhNhNubh)}(h ``kunit.py``h]hkunit.py}(hjFhhhNhNubah}(h]h ]h"]h$]h&]uh1hhj>ubh] (before 5.6) didn’t work unless run from the kernel root, hence the use of a subshell and }(hj>hhhNhNubh)}(h``cd``h]hcd}(hjXhhhNhNubah}(h]h ]h"]h$]h&]uh1hhj>ubh.}(hj>hhhNhNubeh}(h]h ]h"]h$]h&]uh1jhhhKhj:ubah}(h]h ]h"]h$]h&]uh1j8hjhhhhhNubeh}(h]running-from-any-directoryah ]h"]running from any directoryah$]h&]uh1hhhhhhhhK ubh)}(hhh](h)}(hRunning a subset of testsh]hRunning a subset of tests}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhj~hhhhhKubj)}(hq``kunit.py run`` accepts an optional glob argument to filter tests. The format is ``"[.test_glob]"``.h](h)}(h``kunit.py run``h]h kunit.py run}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjubhB accepts an optional glob argument to filter tests. The format is }(hjhhhNhNubh)}(h``"[.test_glob]"``h]h"[.test_glob]"}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjubh.}(hjhhhNhNubeh}(h]h ]h"]h$]h&]uh1jhhhKhj~hhubj)}(h?Say that we wanted to run the sysctl tests, we could do so via:h]h?Say that we wanted to run the sysctl tests, we could do so via:}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1jhhhKhj~hhubj$)}(hy$ echo -e 'CONFIG_KUNIT=y\nCONFIG_KUNIT_ALL_TESTS=y' > .kunit/.kunitconfig $ ./tools/testing/kunit/kunit.py run 'sysctl*'h]hy$ echo -e 'CONFIG_KUNIT=y\nCONFIG_KUNIT_ALL_TESTS=y' > .kunit/.kunitconfig $ ./tools/testing/kunit/kunit.py run 'sysctl*'}hjsbah}(h]h ]h"]h$]h&]hhj3j4bashj6}uh1j#hhhK!hj~hhubj)}(h1We can filter down to just the "write" tests via:h]h5We can filter down to just the “write” tests via:}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1jhhhK&hj~hhubj$)}(h$ echo -e 'CONFIG_KUNIT=y\nCONFIG_KUNIT_ALL_TESTS=y' > .kunit/.kunitconfig $ ./tools/testing/kunit/kunit.py run 'sysctl*.*write*'h]h$ echo -e 'CONFIG_KUNIT=y\nCONFIG_KUNIT_ALL_TESTS=y' > .kunit/.kunitconfig $ ./tools/testing/kunit/kunit.py run 'sysctl*.*write*'}hjsbah}(h]h ]h"]h$]h&]hhj3j4bashj6}uh1j#hhhK(hj~hhubj)}(hWe're paying the cost of building more tests than we need this way, but it's easier than fiddling with ``.kunitconfig`` files or commenting out ``kunit_suite``'s.h](hkWe’re paying the cost of building more tests than we need this way, but it’s easier than fiddling with }(hjhhhNhNubh)}(h``.kunitconfig``h]h .kunitconfig}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjubh files or commenting out }(hjhhhNhNubh)}(h``kunit_suite``h]h kunit_suite}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjubh’s.}(hjhhhNhNubeh}(h]h ]h"]h$]h&]uh1jhhhK-hj~hhubj)}(h\However, if we wanted to define a set of tests in a less ad hoc way, the next tip is useful.h]h\However, if we wanted to define a set of tests in a less ad hoc way, the next tip is useful.}(hj+hhhNhNubah}(h]h ]h"]h$]h&]uh1jhhhK1hj~hhubeh}(h]running-a-subset-of-testsah ]h"]running a subset of testsah$]h&]uh1hhhhhhhhKubh)}(hhh](h)}(hDefining a set of testsh]hDefining a set of tests}(hjDhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjAhhhhhK5ubj)}(hX``kunit.py run`` (along with ``build``, and ``config``) supports a ``--kunitconfig`` flag. So if you have a set of tests that you want to run on a regular basis (especially if they have other dependencies), you can create a specific ``.kunitconfig`` for them.h](h)}(h``kunit.py run``h]h kunit.py run}(hjVhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjRubh (along with }(hjRhhhNhNubh)}(h ``build``h]hbuild}(hjhhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjRubh, and }(hjRhhhNhNubh)}(h ``config``h]hconfig}(hjzhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjRubh ) supports a }(hjRhhhNhNubh)}(h``--kunitconfig``h]h --kunitconfig}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjRubh flag. So if you have a set of tests that you want to run on a regular basis (especially if they have other dependencies), you can create a specific }(hjRhhhNhNubh)}(h``.kunitconfig``h]h .kunitconfig}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjRubh for them.}(hjRhhhNhNubeh}(h]h ]h"]h$]h&]uh1jhhhK7hjAhhubj)}(h!E.g. kunit has one for its tests:h]h!E.g. kunit has one for its tests:}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1jhhhKhjAhhubj)}(hzAlternatively, if you're following the convention of naming your file ``.kunitconfig``, you can just pass in the dir, e.g.h](hHAlternatively, if you’re following the convention of naming your file }(hjhhhNhNubh)}(h``.kunitconfig``h]h .kunitconfig}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjubh$, you can just pass in the dir, e.g.}(hjhhhNhNubeh}(h]h ]h"]h$]h&]uh1jhhhKBhjAhhubj$)}(h<$ ./tools/testing/kunit/kunit.py run --kunitconfig=lib/kunith]h<$ ./tools/testing/kunit/kunit.py run --kunitconfig=lib/kunit}hjsbah}(h]h ]h"]h$]h&]hhj3j4bashj6}uh1j#hhhKEhjAhhubj9)}(hX This is a relatively new feature (5.12+) so we don't have any conventions yet about on what files should be checked in versus just kept around locally. It's up to you and your maintainer to decide if a config is useful enough to submit (and therefore have to maintain).h]j)}(hX This is a relatively new feature (5.12+) so we don't have any conventions yet about on what files should be checked in versus just kept around locally. It's up to you and your maintainer to decide if a config is useful enough to submit (and therefore have to maintain).h]hXThis is a relatively new feature (5.12+) so we don’t have any conventions yet about on what files should be checked in versus just kept around locally. It’s up to you and your maintainer to decide if a config is useful enough to submit (and therefore have to maintain).}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1jhhhKJhjubah}(h]h ]h"]h$]h&]uh1j8hjAhhhhhNubj9)}(hXHaving ``.kunitconfig`` fragments in a parent and child directory is iffy. There's discussion about adding an "import" statement in these files to make it possible to have a top-level config run tests from all child directories. But that would mean ``.kunitconfig`` files are no longer just simple .config fragments. One alternative would be to have kunit tool recursively combine configs automagically, but tests could theoretically depend on incompatible options, so handling that would be tricky.h](j)}(hX<Having ``.kunitconfig`` fragments in a parent and child directory is iffy. There's discussion about adding an "import" statement in these files to make it possible to have a top-level config run tests from all child directories. But that would mean ``.kunitconfig`` files are no longer just simple .config fragments.h](hHaving }(hj hhhNhNubh)}(h``.kunitconfig``h]h .kunitconfig}(hj(hhhNhNubah}(h]h ]h"]h$]h&]uh1hhj ubh fragments in a parent and child directory is iffy. There’s discussion about adding an “import” statement in these files to make it possible to have a top-level config run tests from all child directories. But that would mean }(hj hhhNhNubh)}(h``.kunitconfig``h]h .kunitconfig}(hj:hhhNhNubah}(h]h ]h"]h$]h&]uh1hhj ubh3 files are no longer just simple .config fragments.}(hj hhhNhNubeh}(h]h ]h"]h$]h&]uh1jhhhKPhjubj)}(hOne alternative would be to have kunit tool recursively combine configs automagically, but tests could theoretically depend on incompatible options, so handling that would be tricky.h]hOne alternative would be to have kunit tool recursively combine configs automagically, but tests could theoretically depend on incompatible options, so handling that would be tricky.}(hjRhhhNhNubah}(h]h ]h"]h$]h&]uh1jhhhKVhjubeh}(h]h ]h"]h$]h&]uh1j8hjAhhhhhNubeh}(h]defining-a-set-of-testsah ]h"]defining a set of testsah$]h&]uh1hhhhhhhhK5ubh)}(hhh](h)}(h%Setting kernel commandline parametersh]h%Setting kernel commandline parameters}(hjqhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjnhhhhhK[ubj)}(hFYou can use ``--kernel_args`` to pass arbitrary kernel arguments, e.g.h](h You can use }(hjhhhNhNubh)}(h``--kernel_args``h]h --kernel_args}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjubh) to pass arbitrary kernel arguments, e.g.}(hjhhhNhNubeh}(h]h ]h"]h$]h&]uh1jhhhK]hjnhhubj$)}(hV$ ./tools/testing/kunit/kunit.py run --kernel_args=param=42 --kernel_args=param2=falseh]hV$ ./tools/testing/kunit/kunit.py run --kernel_args=param=42 --kernel_args=param2=false}hjsbah}(h]h ]h"]h$]h&]hhj3j4bashj6}uh1j#hhhK_hjnhhubeh}(h]%setting-kernel-commandline-parametersah ]h"]%setting kernel commandline parametersah$]h&]uh1hhhhhhhhK[ubh)}(hhh](h)}(h*Generating code coverage reports under UMLh]h*Generating code coverage reports under UML}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjhhhhhKeubj9)}(hTODO(brendanhiggins@google.com): There are various issues with UML and versions of gcc 7 and up. You're likely to run into missing ``.gcda`` files or compile errors.h]j)}(hTODO(brendanhiggins@google.com): There are various issues with UML and versions of gcc 7 and up. You're likely to run into missing ``.gcda`` files or compile errors.h](hTODO(}(hjhhhNhNubh reference)}(hbrendanhiggins@google.comh]hbrendanhiggins@google.com}(hjhhhNhNubah}(h]h ]h"]h$]h&]refuri mailto:brendanhiggins@google.comuh1jhjubhg): There are various issues with UML and versions of gcc 7 and up. You’re likely to run into missing }(hjhhhNhNubh)}(h ``.gcda``h]h.gcda}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjubh files or compile errors.}(hjhhhNhNubeh}(h]h ]h"]h$]h&]uh1jhhhKhhjubah}(h]h ]h"]h$]h&]uh1j8hjhhhhhNubj)}(hThis is different from the "normal" way of getting coverage information that is documented in Documentation/dev-tools/gcov.rst.h]hThis is different from the “normal” way of getting coverage information that is documented in Documentation/dev-tools/gcov.rst.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1jhhhKlhjhhubj)}(hGInstead of enabling ``CONFIG_GCOV_KERNEL=y``, we can set these options:h](hInstead of enabling }(hjhhhNhNubh)}(h``CONFIG_GCOV_KERNEL=y``h]hCONFIG_GCOV_KERNEL=y}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjubh, we can set these options:}(hjhhhNhNubeh}(h]h ]h"]h$]h&]uh1jhhhKohjhhubj$)}(hcCONFIG_DEBUG_KERNEL=y CONFIG_DEBUG_INFO=y CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT=y CONFIG_GCOV=yh]hcCONFIG_DEBUG_KERNEL=y CONFIG_DEBUG_INFO=y CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT=y CONFIG_GCOV=y}hj6sbah}(h]h ]h"]h$]h&]hhj3j4nonej6}uh1j#hhhKqhjhhubj)}(h>Putting it together into a copy-pastable sequence of commands:h]h>Putting it together into a copy-pastable sequence of commands:}(hjFhhhNhNubah}(h]h ]h"]h$]h&]uh1jhhhKyhjhhubj$)}(hX# Append coverage options to the current config $ ./tools/testing/kunit/kunit.py run --kunitconfig=.kunit/ --kunitconfig=tools/testing/kunit/configs/coverage_uml.config # Extract the coverage information from the build dir (.kunit/) $ lcov -t "my_kunit_tests" -o coverage.info -c -d .kunit/ # From here on, it's the same process as with CONFIG_GCOV_KERNEL=y # E.g. can generate an HTML report in a tmp dir like so: $ genhtml -o /tmp/coverage_html coverage.infoh]hX# Append coverage options to the current config $ ./tools/testing/kunit/kunit.py run --kunitconfig=.kunit/ --kunitconfig=tools/testing/kunit/configs/coverage_uml.config # Extract the coverage information from the build dir (.kunit/) $ lcov -t "my_kunit_tests" -o coverage.info -c -d .kunit/ # From here on, it's the same process as with CONFIG_GCOV_KERNEL=y # E.g. can generate an HTML report in a tmp dir like so: $ genhtml -o /tmp/coverage_html coverage.info}hjTsbah}(h]h ]h"]h$]h&]hhj3j4bashj6}uh1j#hhhK{hjhhubj)}(hGIf your installed version of gcc doesn't work, you can tweak the steps:h]hIIf your installed version of gcc doesn’t work, you can tweak the steps:}(hjdhhhNhNubah}(h]h ]h"]h$]h&]uh1jhhhKhjhhubj$)}(h$ ./tools/testing/kunit/kunit.py run --make_options=CC=/usr/bin/gcc-6 $ lcov -t "my_kunit_tests" -o coverage.info -c -d .kunit/ --gcov-tool=/usr/bin/gcov-6h]h$ ./tools/testing/kunit/kunit.py run --make_options=CC=/usr/bin/gcc-6 $ lcov -t "my_kunit_tests" -o coverage.info -c -d .kunit/ --gcov-tool=/usr/bin/gcov-6}hjrsbah}(h]h ]h"]h$]h&]hhj3j4bashj6}uh1j#hhhKhjhhubj)}(h6Alternatively, LLVM-based toolchains can also be used:h]h6Alternatively, LLVM-based toolchains can also be used:}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1jhhhKhjhhubj$)}(hX# Build with LLVM and append coverage options to the current config $ ./tools/testing/kunit/kunit.py run --make_options LLVM=1 --kunitconfig=.kunit/ --kunitconfig=tools/testing/kunit/configs/coverage_uml.config $ llvm-profdata merge -sparse default.profraw -o default.profdata $ llvm-cov export --format=lcov .kunit/vmlinux -instr-profile default.profdata > coverage.info # The coverage.info file is in lcov-compatible format and it can be used to e.g. generate HTML report $ genhtml -o /tmp/coverage_html coverage.infoh]hX# Build with LLVM and append coverage options to the current config $ ./tools/testing/kunit/kunit.py run --make_options LLVM=1 --kunitconfig=.kunit/ --kunitconfig=tools/testing/kunit/configs/coverage_uml.config $ llvm-profdata merge -sparse default.profraw -o default.profdata $ llvm-cov export --format=lcov .kunit/vmlinux -instr-profile default.profdata > coverage.info # The coverage.info file is in lcov-compatible format and it can be used to e.g. generate HTML report $ genhtml -o /tmp/coverage_html coverage.info}hjsbah}(h]h ]h"]h$]h&]hhj3j4bashj6}uh1j#hhhKhjhhubeh}(h]*generating-code-coverage-reports-under-umlah ]h"]*generating code coverage reports under umlah$]h&]uh1hhhhhhhhKeubeh}(h]using-kunit-py-run-kunit-toolah ]h"]!using kunit.py run ("kunit tool")ah$]h&]uh1hhhhhhhhKubh)}(hhh](h)}(hRunning tests manuallyh]hRunning tests manually}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjhhhhhKubj)}(hRunning tests without using ``kunit.py run`` is also an important use case. Currently it's your only option if you want to test on architectures other than UML.h](hRunning tests without using }(hjhhhNhNubh)}(h``kunit.py run``h]h kunit.py run}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjubhv is also an important use case. Currently it’s your only option if you want to test on architectures other than UML.}(hjhhhNhNubeh}(h]h ]h"]h$]h&]uh1jhhhKhjhhubj)}(hAs running the tests under UML is fairly straightforward (configure and compile the kernel, run the ``./linux`` binary), this section will focus on testing non-UML architectures.h](hdAs running the tests under UML is fairly straightforward (configure and compile the kernel, run the }(hjhhhNhNubh)}(h ``./linux``h]h./linux}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjubhC binary), this section will focus on testing non-UML architectures.}(hjhhhNhNubeh}(h]h ]h"]h$]h&]uh1jhhhKhjhhubh)}(hhh](h)}(hRunning built-in testsh]hRunning built-in tests}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjhhhhhKubj)}(hWhen setting tests to ``=y``, the tests will run as part of boot and print results to dmesg in TAP format. So you just need to add your tests to your ``.config``, build and boot your kernel as normal.h](hWhen setting tests to }(hjhhhNhNubh)}(h``=y``h]h=y}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjubhz, the tests will run as part of boot and print results to dmesg in TAP format. So you just need to add your tests to your }(hjhhhNhNubh)}(h ``.config``h]h.config}(hj,hhhNhNubah}(h]h ]h"]h$]h&]uh1hhjubh', build and boot your kernel as normal.}(hjhhhNhNubeh}(h]h ]h"]h$]h&]uh1jhhhKhjhhubj)}(h"So if we compiled our kernel with:h]h"So if we compiled our kernel with:}(hjDhhhNhNubah}(h]h ]h"]h$]h&]uh1jhhhKhjhhubj$)}(h*CONFIG_KUNIT=y CONFIG_KUNIT_EXAMPLE_TEST=yh]h*CONFIG_KUNIT=y CONFIG_KUNIT_EXAMPLE_TEST=y}hjRsbah}(h]h ]h"]h$]h&]hhj3j4nonej6}uh1j#hhhKhjhhubj)}(hJThen we'd see output like this in dmesg signaling the test ran and passed:h]hLThen we’d see output like this in dmesg signaling the test ran and passed:}(hjbhhhNhNubah}(h]h ]h"]h$]h&]uh1jhhhKhjhhubj$)}(hTAP version 14 1..1 # Subtest: example 1..1 # example_simple_test: initializing ok 1 - example_simple_test ok 1 - exampleh]hTAP version 14 1..1 # Subtest: example 1..1 # example_simple_test: initializing ok 1 - example_simple_test ok 1 - example}hjpsbah}(h]h ]h"]h$]h&]hhj3j4nonej6}uh1j#hhhKhjhhubeh}(h]running-built-in-testsah ]h"]running built-in testsah$]h&]uh1hhjhhhhhKubh)}(hhh](h)}(hRunning tests as modulesh]hRunning tests as modules}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjhhhhhKubj)}(h?Depending on the tests, you can build them as loadable modules.h]h?Depending on the tests, you can build them as loadable modules.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1jhhhKhjhhubj)}(h:For example, we'd change the config options from before toh]hkunit_test`` will not exist.h]j)}(hXJYou can set ``CONFIG_KUNIT=m`` as well, however, some features will not work and thus some tests might break. Ideally tests would specify they depend on ``KUNIT=y`` in their ``Kconfig``'s, but this is an edge case most test authors won't think about. As of 5.13, the only difference is that ``current->kunit_test`` will not exist.h](h You can set }(hjEhhhNhNubh)}(h``CONFIG_KUNIT=m``h]hCONFIG_KUNIT=m}(hjMhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjEubh{ as well, however, some features will not work and thus some tests might break. Ideally tests would specify they depend on }(hjEhhhNhNubh)}(h ``KUNIT=y``h]hKUNIT=y}(hj_hhhNhNubah}(h]h ]h"]h$]h&]uh1hhjEubh in their }(hjEhhhNhNubh)}(h ``Kconfig``h]hKconfig}(hjqhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjEubhn’s, but this is an edge case most test authors won’t think about. As of 5.13, the only difference is that }(hjEhhhNhNubh)}(h``current->kunit_test``h]hcurrent->kunit_test}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjEubh will not exist.}(hjEhhhNhNubeh}(h]h ]h"]h$]h&]uh1jhhhKhjAubah}(h]h ]h"]h$]h&]uh1j8hjhhhhhNubeh}(h]running-tests-as-modulesah ]h"]running tests as modulesah$]h&]uh1hhjhhhhhKubh)}(hhh](h)}(hPretty-printing resultsh]hPretty-printing results}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjhhhhhKubj)}(hYou can use ``kunit.py parse`` to parse dmesg for test output and print out results in the same familiar format that ``kunit.py run`` does.h](h You can use }(hjhhhNhNubh)}(h``kunit.py parse``h]hkunit.py parse}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjubhW to parse dmesg for test output and print out results in the same familiar format that }(hjhhhNhNubh)}(h``kunit.py run``h]h kunit.py run}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjubh does.}(hjhhhNhNubeh}(h]h ]h"]h$]h&]uh1jhhhKhjhhubj$)}(h5$ ./tools/testing/kunit/kunit.py parse /var/log/dmesgh]h5$ ./tools/testing/kunit/kunit.py parse /var/log/dmesg}hjsbah}(h]h ]h"]h$]h&]hhj3j4bashj6}uh1j#hhhKhjhhubeh}(h]pretty-printing-resultsah ]h"]pretty-printing resultsah$]h&]uh1hhjhhhhhKubh)}(hhh](h)}(hRetrieving per suite resultsh]hRetrieving per suite results}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjhhhhhKubj)}(hRegardless of how you're running your tests, you can enable ``CONFIG_KUNIT_DEBUGFS`` to expose per-suite TAP-formatted results:h](h>Regardless of how you’re running your tests, you can enable }(hjhhhNhNubh)}(h``CONFIG_KUNIT_DEBUGFS``h]hCONFIG_KUNIT_DEBUGFS}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjubh+ to expose per-suite TAP-formatted results:}(hjhhhNhNubeh}(h]h ]h"]h$]h&]uh1jhhhKhjhhubj$)}(hACONFIG_KUNIT=y CONFIG_KUNIT_EXAMPLE_TEST=m CONFIG_KUNIT_DEBUGFS=yh]hACONFIG_KUNIT=y CONFIG_KUNIT_EXAMPLE_TEST=m CONFIG_KUNIT_DEBUGFS=y}hj5sbah}(h]h ]h"]h$]h&]hhj3j4nonej6}uh1j#hhhKhjhhubj)}(hzThe results for each suite will be exposed under ``/sys/kernel/debug/kunit//results``. So using our example config:h](h1The results for each suite will be exposed under }(hjEhhhNhNubh)}(h+``/sys/kernel/debug/kunit//results``h]h'/sys/kernel/debug/kunit//results}(hjMhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjEubh. So using our example config:}(hjEhhhNhNubeh}(h]h ]h"]h$]h&]uh1jhhhKhjhhubj$)}(hXA$ modprobe kunit-example-test > /dev/null $ cat /sys/kernel/debug/kunit/example/results ... ... # After removing the module, the corresponding files will go away $ modprobe -r kunit-example-test $ cat /sys/kernel/debug/kunit/example/results /sys/kernel/debug/kunit/example/results: No such file or directoryh]hXA$ modprobe kunit-example-test > /dev/null $ cat /sys/kernel/debug/kunit/example/results ... ... # After removing the module, the corresponding files will go away $ modprobe -r kunit-example-test $ cat /sys/kernel/debug/kunit/example/results /sys/kernel/debug/kunit/example/results: No such file or directory}hjesbah}(h]h ]h"]h$]h&]hhj3j4bashj6}uh1j#hhhKhjhhubeh}(h]retrieving-per-suite-resultsah ]h"]retrieving per suite resultsah$]h&]uh1hhjhhhhhKubh)}(hhh](h)}(h Generating code coverage reportsh]h Generating code coverage reports}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhj}hhhhhMubj)}(hCSee Documentation/dev-tools/gcov.rst for details on how to do this.h]hCSee Documentation/dev-tools/gcov.rst for details on how to do this.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1jhhhM hj}hhubj)}(hThe only vaguely KUnit-specific advice here is that you probably want to build your tests as modules. That way you can isolate the coverage from tests from other code executed during boot, e.g.h]hThe only vaguely KUnit-specific advice here is that you probably want to build your tests as modules. That way you can isolate the coverage from tests from other code executed during boot, e.g.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1jhhhM hj}hhubj$)}(hx# Reset coverage counters before running the test. $ echo 0 > /sys/kernel/debug/gcov/reset $ modprobe kunit-example-testh]hx# Reset coverage counters before running the test. $ echo 0 > /sys/kernel/debug/gcov/reset $ modprobe kunit-example-test}hjsbah}(h]h ]h"]h$]h&]hhj3j4bashj6}uh1j#hhhMhj}hhubeh}(h] generating-code-coverage-reportsah ]h"] generating code coverage reportsah$]h&]uh1hhjhhhhhMubeh}(h]running-tests-manuallyah ]h"]running tests manuallyah$]h&]uh1hhhhhhhhKubh)}(hhh](h)}(hTest Attributes and Filteringh]hTest Attributes and Filtering}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjhhhhhMubj)}(hTest suites and cases can be marked with test attributes, such as speed of test. These attributes will later be printed in test output and can be used to filter test execution.h]hTest suites and cases can be marked with test attributes, such as speed of test. These attributes will later be printed in test output and can be used to filter test execution.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1jhhhMhjhhubh)}(hhh](h)}(hMarking Test Attributesh]hMarking Test Attributes}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjhhhhhMubj)}(heTests are marked with an attribute by including a ``kunit_attributes`` object in the test definition.h](h2Tests are marked with an attribute by including a }(hjhhhNhNubh)}(h``kunit_attributes``h]hkunit_attributes}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjubh object in the test definition.}(hjhhhNhNubeh}(h]h ]h"]h$]h&]uh1jhhhM hjhhubj)}(hTest cases can be marked using the ``KUNIT_CASE_ATTR(test_name, attributes)`` macro to define the test case instead of ``KUNIT_CASE(test_name)``.h](h#Test cases can be marked using the }(hjhhhNhNubh)}(h*``KUNIT_CASE_ATTR(test_name, attributes)``h]h&KUNIT_CASE_ATTR(test_name, attributes)}(hj"hhhNhNubah}(h]h ]h"]h$]h&]uh1hhjubh* macro to define the test case instead of }(hjhhhNhNubh)}(h``KUNIT_CASE(test_name)``h]hKUNIT_CASE(test_name)}(hj4hhhNhNubah}(h]h ]h"]h$]h&]uh1hhjubh.}(hjhhhNhNubeh}(h]h ]h"]h$]h&]uh1jhhhM#hjhhubj$)}(hstatic const struct kunit_attributes example_attr = { .speed = KUNIT_VERY_SLOW, }; static struct kunit_case example_test_cases[] = { KUNIT_CASE_ATTR(example_test, example_attr), };h]hstatic const struct kunit_attributes example_attr = { .speed = KUNIT_VERY_SLOW, }; static struct kunit_case example_test_cases[] = { KUNIT_CASE_ATTR(example_test, example_attr), };}hjLsbah}(h]h ]h"]h$]h&]hhj3j4cj6}uh1j#hhhM&hjhhubj9)}(hTo mark a test case as slow, you can also use ``KUNIT_CASE_SLOW(test_name)``. This is a helpful macro as the slow attribute is the most commonly used.h]j)}(hTo mark a test case as slow, you can also use ``KUNIT_CASE_SLOW(test_name)``. This is a helpful macro as the slow attribute is the most commonly used.h](h.To mark a test case as slow, you can also use }(hj`hhhNhNubh)}(h``KUNIT_CASE_SLOW(test_name)``h]hKUNIT_CASE_SLOW(test_name)}(hjhhhhNhNubah}(h]h ]h"]h$]h&]uh1hhj`ubhJ. This is a helpful macro as the slow attribute is the most commonly used.}(hj`hhhNhNubeh}(h]h ]h"]h$]h&]uh1jhhhM1hj\ubah}(h]h ]h"]h$]h&]uh1j8hjhhhhhNubj)}(h`Test suites can be marked with an attribute by setting the "attr" field in the suite definition.h]hdTest suites can be marked with an attribute by setting the “attr” field in the suite definition.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1jhhhM4hjhhubj$)}(hstatic const struct kunit_attributes example_attr = { .speed = KUNIT_VERY_SLOW, }; static struct kunit_suite example_test_suite = { ..., .attr = example_attr, };h]hstatic const struct kunit_attributes example_attr = { .speed = KUNIT_VERY_SLOW, }; static struct kunit_suite example_test_suite = { ..., .attr = example_attr, };}hjsbah}(h]h ]h"]h$]h&]hhj3j4jZj6}uh1j#hhhM7hjhhubj9)}(hXANot all attributes need to be set in a ``kunit_attributes`` object. Unset attributes will remain uninitialized and act as though the attribute is set to 0 or NULL. Thus, if an attribute is set to 0, it is treated as unset. These unset attributes will not be reported and may act as a default value for filtering purposes.h]j)}(hXANot all attributes need to be set in a ``kunit_attributes`` object. Unset attributes will remain uninitialized and act as though the attribute is set to 0 or NULL. Thus, if an attribute is set to 0, it is treated as unset. These unset attributes will not be reported and may act as a default value for filtering purposes.h](h'Not all attributes need to be set in a }(hjhhhNhNubh)}(h``kunit_attributes``h]hkunit_attributes}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjubhX object. Unset attributes will remain uninitialized and act as though the attribute is set to 0 or NULL. Thus, if an attribute is set to 0, it is treated as unset. These unset attributes will not be reported and may act as a default value for filtering purposes.}(hjhhhNhNubeh}(h]h ]h"]h$]h&]uh1jhhhMChjubah}(h]h ]h"]h$]h&]uh1j8hjhhhhhNubeh}(h]marking-test-attributesah ]h"]marking test attributesah$]h&]uh1hhjhhhhhMubh)}(hhh](h)}(hReporting Attributesh]hReporting Attributes}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjhhhhhMJubj)}(hX]When a user runs tests, attributes will be present in the raw kernel output (in KTAP format). Note that attributes will be hidden by default in kunit.py output for all passing tests but the raw kernel output can be accessed using the ``--raw_output`` flag. This is an example of how test attributes for test cases will be formatted in kernel output:h](hWhen a user runs tests, attributes will be present in the raw kernel output (in KTAP format). Note that attributes will be hidden by default in kunit.py output for all passing tests but the raw kernel output can be accessed using the }(hjhhhNhNubh)}(h``--raw_output``h]h --raw_output}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjubhc flag. This is an example of how test attributes for test cases will be formatted in kernel output:}(hjhhhNhNubeh}(h]h ]h"]h$]h&]uh1jhhhMLhjhhubj$)}(h,# example_test.speed: slow ok 1 example_testh]h,# example_test.speed: slow ok 1 example_test}hj sbah}(h]h ]h"]h$]h&]hhj3j4nonej6}uh1j#hhhMRhjhhubj)}(h]This is an example of how test attributes for test suites will be formatted in kernel output:h]h]This is an example of how test attributes for test suites will be formatted in kernel output:}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1jhhhMWhjhhubj$)}(hj KTAP version 2 # Subtest: example_suite # module: kunit_example_test 1..3 ... ok 1 example_suiteh]hj KTAP version 2 # Subtest: example_suite # module: kunit_example_test 1..3 ... ok 1 example_suite}hj$ sbah}(h]h ]h"]h$]h&]hhj3j4nonej6}uh1j#hhhMZhjhhubj)}(hAdditionally, users can output a full attribute report of tests with their attributes, using the command line flag ``--list_tests_attr``:h](hsAdditionally, users can output a full attribute report of tests with their attributes, using the command line flag }(hj4 hhhNhNubh)}(h``--list_tests_attr``h]h--list_tests_attr}(hj< hhhNhNubah}(h]h ]h"]h$]h&]uh1hhj4 ubh:}(hj4 hhhNhNubeh}(h]h ]h"]h$]h&]uh1jhhhMchjhhubj$)}(h(kunit.py run "example" --list_tests_attrh]h(kunit.py run "example" --list_tests_attr}hjT sbah}(h]h ]h"]h$]h&]hhj3j4bashj6}uh1j#hhhMfhjhhubj9)}(hrThis report can be accessed when running KUnit manually by passing in the module_param ``kunit.action=list_attr``.h]j)}(hrThis report can be accessed when running KUnit manually by passing in the module_param ``kunit.action=list_attr``.h](hWThis report can be accessed when running KUnit manually by passing in the module_param }(hjh hhhNhNubh)}(h``kunit.action=list_attr``h]hkunit.action=list_attr}(hjp hhhNhNubah}(h]h ]h"]h$]h&]uh1hhjh ubh.}(hjh hhhNhNubeh}(h]h ]h"]h$]h&]uh1jhhhMkhjd ubah}(h]h ]h"]h$]h&]uh1j8hjhhhhhNubeh}(h]reporting-attributesah ]h"]reporting attributesah$]h&]uh1hhjhhhhhMJubh)}(hhh](h)}(h Filteringh]h Filtering}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhj hhhhhMoubj)}(hbUsers can filter tests using the ``--filter`` command line flag when running tests. As an example:h](h!Users can filter tests using the }(hj hhhNhNubh)}(h ``--filter``h]h--filter}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhj ubh5 command line flag when running tests. As an example:}(hj hhhNhNubeh}(h]h ]h"]h$]h&]uh1jhhhMqhj hhubj$)}(h kunit.py run --filter speed=slowh]h kunit.py run --filter speed=slow}hj sbah}(h]h ]h"]h$]h&]hhj3j4bashj6}uh1j#hhhMthj hhubj)}(hcYou can also use the following operations on filters: "<", ">", "<=", ">=", "!=", and "=". Example:h]h{You can also use the following operations on filters: “<”, “>”, “<=”, “>=”, “!=”, and “=”. Example:}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1jhhhMyhj hhubj$)}(h"kunit.py run --filter "speed>slow"h]h"kunit.py run --filter "speed>slow"}hj sbah}(h]h ]h"]h$]h&]hhj3j4bashj6}uh1j#hhhM|hj hhubj)}(hThis example will run all tests with speeds faster than slow. Note that the characters < and > are often interpreted by the shell, so they may need to be quoted or escaped, as above.h]hThis example will run all tests with speeds faster than slow. Note that the characters < and > are often interpreted by the shell, so they may need to be quoted or escaped, as above.}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1jhhhMhj hhubj)}(hbAdditionally, you can use multiple filters at once. Simply separate filters using commas. Example:h]hbAdditionally, you can use multiple filters at once. Simply separate filters using commas. Example:}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1jhhhMhj hhubj$)}(h=kunit.py run --filter "speed>slow, module=kunit_example_test"h]h=kunit.py run --filter "speed>slow, module=kunit_example_test"}hj sbah}(h]h ]h"]h$]h&]hhj3j4bashj6}uh1j#hhhMhj hhubj9)}(hYou can use this filtering feature when running KUnit manually by passing the filter as a module param: ``kunit.filter="speed>slow, speed<=normal"``.h]j)}(hYou can use this filtering feature when running KUnit manually by passing the filter as a module param: ``kunit.filter="speed>slow, speed<=normal"``.h](hhYou can use this filtering feature when running KUnit manually by passing the filter as a module param: }(hj% hhhNhNubh)}(h,``kunit.filter="speed>slow, speed<=normal"``h]h(kunit.filter="speed>slow, speed<=normal"}(hj- hhhNhNubah}(h]h ]h"]h$]h&]uh1hhj% ubh.}(hj% hhhNhNubeh}(h]h ]h"]h$]h&]uh1jhhhMhj! ubah}(h]h ]h"]h$]h&]uh1j8hj hhhhhNubj)}(hX7Filtered tests will not run or show up in the test output. You can use the ``--filter_action=skip`` flag to skip filtered tests instead. These tests will be shown in the test output in the test but will not run. To use this feature when running KUnit manually, use the module param ``kunit.filter_action=skip``.h](hKFiltered tests will not run or show up in the test output. You can use the }(hjK hhhNhNubh)}(h``--filter_action=skip``h]h--filter_action=skip}(hjS hhhNhNubah}(h]h ]h"]h$]h&]uh1hhjK ubh flag to skip filtered tests instead. These tests will be shown in the test output in the test but will not run. To use this feature when running KUnit manually, use the module param }(hjK hhhNhNubh)}(h``kunit.filter_action=skip``h]hkunit.filter_action=skip}(hje hhhNhNubah}(h]h ]h"]h$]h&]uh1hhjK ubh.}(hjK hhhNhNubeh}(h]h ]h"]h$]h&]uh1jhhhMhj hhubeh}(h] filteringah ]h"] filteringah$]h&]uh1hhjhhhhhMoubh)}(hhh](h)}(hRules of Filtering Procedureh]hRules of Filtering Procedure}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhj hhhhhMubj)}(hSince both suites and test cases can have attributes, there may be conflicts between attributes during filtering. The process of filtering follows these rules:h]hSince both suites and test cases can have attributes, there may be conflicts between attributes during filtering. The process of filtering follows these rules:}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1jhhhMhj hhubh bullet_list)}(hhh](h list_item)}(h/Filtering always operates at a per-test level. h]j)}(h.Filtering always operates at a per-test level.h]h.Filtering always operates at a per-test level.}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1jhhhMhj ubah}(h]h ]h"]h$]h&]uh1j hj hhhhhNubj )}(hFIf a test has an attribute set, then the test's value is filtered on. h]j)}(hEIf a test has an attribute set, then the test's value is filtered on.h]hGIf a test has an attribute set, then the test’s value is filtered on.}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1jhhhMhj ubah}(h]h ]h"]h$]h&]uh1j hj hhhhhNubj )}(h6Otherwise, the value falls back to the suite's value. h]j)}(h5Otherwise, the value falls back to the suite's value.h]h7Otherwise, the value falls back to the suite’s value.}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1jhhhMhj ubah}(h]h ]h"]h$]h&]uh1j hj hhhhhNubj )}(hOIf neither are set, the attribute has a global "default" value, which is used. h]j)}(hNIf neither are set, the attribute has a global "default" value, which is used.h]hRIf neither are set, the attribute has a global “default” value, which is used.}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1jhhhMhj ubah}(h]h ]h"]h$]h&]uh1j hj hhhhhNubeh}(h]h ]h"]h$]h&]bullet-uh1j hhhMhj hhubeh}(h]rules-of-filtering-procedureah ]h"]rules of filtering procedureah$]h&]uh1hhjhhhhhMubh)}(hhh](h)}(hList of Current Attributesh]hList of Current Attributes}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhj hhhhhMubj)}(h ``speed``h]h)}(hj. h]hspeed}(hj0 hhhNhNubah}(h]h ]h"]h$]h&]uh1hhj, ubah}(h]h ]h"]h$]h&]uh1jhhhMhj hhubj)}(hXThis attribute indicates the speed of a test's execution (how slow or fast the test is).h]hZThis attribute indicates the speed of a test’s execution (how slow or fast the test is).}(hjC hhhNhNubah}(h]h ]h"]h$]h&]uh1jhhhMhj hhubj)}(hXaThis attribute is saved as an enum with the following categories: "normal", "slow", or "very_slow". The assumed default speed for tests is "normal". This indicates that the test takes a relatively trivial amount of time (less than 1 second), regardless of the machine it is running on. Any test slower than this could be marked as "slow" or "very_slow".h]hXyThis attribute is saved as an enum with the following categories: “normal”, “slow”, or “very_slow”. The assumed default speed for tests is “normal”. This indicates that the test takes a relatively trivial amount of time (less than 1 second), regardless of the machine it is running on. Any test slower than this could be marked as “slow” or “very_slow”.}(hjQ hhhNhNubah}(h]h ]h"]h$]h&]uh1jhhhMhj hhubj)}(hfThe macro ``KUNIT_CASE_SLOW(test_name)`` can be easily used to set the speed of a test case to "slow".h](h The macro }(hj_ hhhNhNubh)}(h``KUNIT_CASE_SLOW(test_name)``h]hKUNIT_CASE_SLOW(test_name)}(hjg hhhNhNubah}(h]h ]h"]h$]h&]uh1hhj_ ubhB can be easily used to set the speed of a test case to “slow”.}(hj_ hhhNhNubeh}(h]h ]h"]h$]h&]uh1jhhhMhj hhubj)}(h ``module``h]h)}(hj h]hmodule}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhj ubah}(h]h ]h"]h$]h&]uh1jhhhMhj hhubj)}(hIThis attribute indicates the name of the module associated with the test.h]hIThis attribute indicates the name of the module associated with the test.}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1jhhhMhj hhubj)}(hThis attribute is automatically saved as a string and is printed for each suite. Tests can also be filtered using this attribute.h]hThis attribute is automatically saved as a string and is printed for each suite. Tests can also be filtered using this attribute.}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1jhhhMhj hhubj)}(h ``is_init``h]h)}(hj h]his_init}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhj ubah}(h]h ]h"]h$]h&]uh1jhhhMhj hhubj)}(hFThis attribute indicates whether the test uses init data or functions.h]hFThis attribute indicates whether the test uses init data or functions.}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1jhhhMhj hhubj)}(hgThis attribute is automatically saved as a boolean and tests can also be filtered using this attribute.h]hgThis attribute is automatically saved as a boolean and tests can also be filtered using this attribute.}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1jhhhMhj hhubeh}(h]list-of-current-attributesah ]h"]list of current attributesah$]h&]uh1hhjhhhhhMubeh}(h]test-attributes-and-filteringah ]h"]test attributes and filteringah$]h&]uh1hhhhhhhhMubeh}(h]tips-for-running-kunit-testsah ]h"]tips for running kunit testsah$]h&]uh1hhhhhhhhKubeh}(h]h ]h"]h$]h&]sourcehuh1hcurrent_sourceN current_lineNsettingsdocutils.frontendValues)}(hN generatorN datestampN source_linkN source_urlN toc_backlinksentryfootnote_backlinksK sectnum_xformKstrip_commentsNstrip_elements_with_classesN strip_classesN report_levelK halt_levelKexit_status_levelKdebugNwarning_streamN tracebackinput_encoding utf-8-siginput_encoding_error_handlerstrictoutput_encodingutf-8output_encoding_error_handlerj error_encodingutf-8error_encoding_error_handlerbackslashreplace language_codeenrecord_dependenciesNconfigN id_prefixhauto_id_prefixid dump_settingsNdump_internalsNdump_transformsNdump_pseudo_xmlNexpose_internalsNstrict_visitorN_disable_configN_sourcehnj _destinationN _config_files]7/var/lib/git/docbuild/linux/Documentation/docutils.confafile_insertion_enabled raw_enabledKline_length_limitM'pep_referencesN pep_base_urlhttps://peps.python.org/pep_file_url_templatepep-%04drfc_referencesN rfc_base_url&https://datatracker.ietf.org/doc/html/ tab_widthKtrim_footnote_reference_spacesyntax_highlightlong smart_quotessmartquotes_locales]character_level_inline_markupdoctitle_xform docinfo_xformKsectsubtitle_xform image_loadinglinkembed_stylesheetcloak_email_addressessection_self_linkenvNubreporterNindirect_targets]substitution_defs}substitution_names}refnames}refids}nameids}(j j jjj{jxj>j;jkjhjjjjjjjjjjjjjzjwjjj j jjj j j j j j j j u nametypes}(j jj{j>jkjjjjjjjzjj jj j j j uh}(j hjhjxjj;j~jhjAjjnjjjjjjjjjjjwjjj}j jjjj jj j j j j j u footnote_refs} citation_refs} autofootnotes]autofootnote_refs]symbol_footnotes]symbol_footnote_refs] footnotes] citations]autofootnote_startKsymbol_footnote_startK id_counter collectionsCounter}Rparse_messages]transform_messages] transformerN include_log] decorationNhhub.