Lines Matching refs:tests

7 To make finding, writing, and using KUnit tests as simple as possible, it's
9 below. While it's 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, or
16 2. Writing tests which would cause serious problems if automatically run (e.g.,
23 In order to make tests as easy to find as possible, they're grouped into suites
24 and subsystems. A test suite is a group of tests which test a related area of
36 MAINTAINERS file. If unsure, follow the conventions set by tests in similar
45 unless you are actually testing other tests or the kunit framework itself.
75         provides a simple, consistent way for humans to find and run tests. This
81 KUnit tests are grouped into test suites, which cover a specific area of
83 shutdown code which is run for all tests in the suite.
91 subsystem (e.g., both unit tests and integration tests), they should be put into
93 Unless these tests are actually present, avoid using ``_test``, ``_unittest`` or
122   tests be added, then that suite could be named ``kasan_unittest`` or similar.
127 Individual tests consist of a single function which tests a constrained
128 codepath, property, or function. In the test output, individual tests' results
133 As tests are C functions, they should be named and written in accordance with
137         As tests are themselves functions, their names cannot conflict with
172 a module), Kconfig entries for tests should be tristate.
183 		  This builds unit tests for foo.
185 		  For more information on KUnit and unit tests in general, please refer
194 KUnit tests can often be compiled as a module. These modules should be named
196 non-KUnit tests, the suffix ``_kunit`` can also be used.