Lines Matching refs:tests
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,
10 they may break some tooling, may conflict with other tests, and may not be run
15 1. Porting tests to KUnit which are already known with an existing name.
16 2. Writing tests which would cause serious problems if automatically run. For
23 To make tests easy to find, they are grouped into suites and subsystems. A test
24 suite is a group of tests which test a related area of the kernel. A subsystem
36 unsure, follow the conventions set by tests in similar areas.
44 unless we are actually testing other tests or the kunit framework itself. For
73 simple, consistent way for humans to find and run tests. This may change
79 KUnit tests are grouped into test suites, which cover a specific area of
81 shutdown code which is run for all tests in the suite. Not all subsystems need
89 subsystem (for example, both unit tests and integration tests), they should be
91 name. Unless these tests are actually present, avoid using ``_test``, ``_unittest``
118 unit tests are added, then that suite could be named as ``kasan_unittest`` or
124 Individual tests consist of a single function which tests a constrained
130 As tests are C functions, they should be named and written in accordance with
134 As tests are themselves functions, their names cannot conflict with
169 be built as a module), Kconfig entries for tests should be tristate.
180 This builds unit tests for foo.
182 For more information on KUnit and unit tests in general,
191 KUnit tests can often be compiled as a module. These modules should be named
193 non-KUnit tests, the suffix ``_kunit`` can also be used.