Lines Matching +full:kunit +full:- +full:base

1 .. SPDX-License-Identifier: GPL-2.0
7 To make finding, writing, and using KUnit tests as simple as possible, it is
9 below. While it is possible to write KUnit tests which do not follow these rules,
15 1. Porting tests to KUnit which are already known with an existing name.
17    example, non-deterministically producing false positives or negatives, or
29 ----------
32 or more KUnit test suites which test the same driver or part of the kernel. A
43 underscores. *Do not* include "test" or "kunit" directly in the subsystem name
44 unless we are actually testing other tests or the kunit framework itself. For
59 ``linear-ranges``
62 ``qos-kunit-test``
63   This name should use underscores, and not have "kunit-test" as a
71         The KUnit API and tools do not explicitly know about subsystems. They are
77 ------
79 KUnit tests are grouped into test suites, which cover a specific area of
88 In the event that there are multiple types of test using KUnit within a
95 the ``.name`` member of the ``kunit_suite`` struct, and forms the base for the
101   Part of the ``kunit`` implementation itself, testing the ``try_catch`` area.
122 ----------
149 the *fully-qualified* name of a test should be the suite name followed by the
162   tested, or be under [Kernel Hacking]->[Kernel Testing and Coverage]
166 * have a brief description of KUnit in the help text.
173 .. code-block:: none
176 		tristate "KUnit test for foo" if !KUNIT_ALL_TESTS
177 		depends on KUNIT
182 		  For more information on KUnit and unit tests in general,
183 		  please refer to the KUnit documentation in Documentation/dev-tools/kunit/.
191 KUnit tests are often compiled as a separate module. To avoid conflicting
192 with regular modules, KUnit modules should be named after the test suite,
194 "foobar_kunit" is the KUnit test module).
199 tab-completion).
203 between KUnit and non-KUnit tests clearer.