Skip to content

Commit e588586

Browse files
rmr167shuahkh
authored andcommitted
kunit: Add documentation of KUnit test attributes
Add documentation on the use of test attributes under the section "Tips for Running KUnit Tests" in the KUnit docs. Documentation includes three sections on how to mark tests with attributes, how attributes are reported, and how the user can filter tests using test attributes. Add descriptions of new flags to list of command-line arguments. Reviewed-by: David Gow <davidgow@google.com> Signed-off-by: Rae Moar <rmoar@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
1 parent 76066f9 commit e588586

File tree

2 files changed

+178
-0
lines changed

2 files changed

+178
-0
lines changed

Documentation/dev-tools/kunit/run_wrapper.rst

Lines changed: 12 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -321,3 +321,15 @@ command line arguments:
321321

322322
- ``--json``: If set, stores the test results in a JSON format and prints to `stdout` or
323323
saves to a file if a filename is specified.
324+
325+
- ``--filter``: Specifies filters on test attributes, for example, ``speed!=slow``.
326+
Multiple filters can be used by wrapping input in quotes and separating filters
327+
by commas. Example: ``--filter "speed>slow, module=example"``.
328+
329+
- ``--filter_action``: If set to ``skip``, filtered tests will be shown as skipped
330+
in the output rather than showing no output.
331+
332+
- ``--list_tests``: If set, lists all tests that will be run.
333+
334+
- ``--list_tests_attr``: If set, lists all tests that will be run and all of their
335+
attributes.

Documentation/dev-tools/kunit/running_tips.rst

Lines changed: 166 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -262,3 +262,169 @@ other code executed during boot, e.g.
262262
# Reset coverage counters before running the test.
263263
$ echo 0 > /sys/kernel/debug/gcov/reset
264264
$ modprobe kunit-example-test
265+
266+
267+
Test Attributes and Filtering
268+
=============================
269+
270+
Test suites and cases can be marked with test attributes, such as speed of
271+
test. These attributes will later be printed in test output and can be used to
272+
filter test execution.
273+
274+
Marking Test Attributes
275+
-----------------------
276+
277+
Tests are marked with an attribute by including a ``kunit_attributes`` object
278+
in the test definition.
279+
280+
Test cases can be marked using the ``KUNIT_CASE_ATTR(test_name, attributes)``
281+
macro to define the test case instead of ``KUNIT_CASE(test_name)``.
282+
283+
.. code-block:: c
284+
285+
static const struct kunit_attributes example_attr = {
286+
.speed = KUNIT_VERY_SLOW,
287+
};
288+
289+
static struct kunit_case example_test_cases[] = {
290+
KUNIT_CASE_ATTR(example_test, example_attr),
291+
};
292+
293+
.. note::
294+
To mark a test case as slow, you can also use ``KUNIT_CASE_SLOW(test_name)``.
295+
This is a helpful macro as the slow attribute is the most commonly used.
296+
297+
Test suites can be marked with an attribute by setting the "attr" field in the
298+
suite definition.
299+
300+
.. code-block:: c
301+
302+
static const struct kunit_attributes example_attr = {
303+
.speed = KUNIT_VERY_SLOW,
304+
};
305+
306+
static struct kunit_suite example_test_suite = {
307+
...,
308+
.attr = example_attr,
309+
};
310+
311+
.. note::
312+
Not all attributes need to be set in a ``kunit_attributes`` object. Unset
313+
attributes will remain uninitialized and act as though the attribute is set
314+
to 0 or NULL. Thus, if an attribute is set to 0, it is treated as unset.
315+
These unset attributes will not be reported and may act as a default value
316+
for filtering purposes.
317+
318+
Reporting Attributes
319+
--------------------
320+
321+
When a user runs tests, attributes will be present in the raw kernel output (in
322+
KTAP format). Note that attributes will be hidden by default in kunit.py output
323+
for all passing tests but the raw kernel output can be accessed using the
324+
``--raw_output`` flag. This is an example of how test attributes for test cases
325+
will be formatted in kernel output:
326+
327+
.. code-block:: none
328+
329+
# example_test.speed: slow
330+
ok 1 example_test
331+
332+
This is an example of how test attributes for test suites will be formatted in
333+
kernel output:
334+
335+
.. code-block:: none
336+
337+
KTAP version 2
338+
# Subtest: example_suite
339+
# module: kunit_example_test
340+
1..3
341+
...
342+
ok 1 example_suite
343+
344+
Additionally, users can output a full attribute report of tests with their
345+
attributes, using the command line flag ``--list_tests_attr``:
346+
347+
.. code-block:: bash
348+
349+
kunit.py run "example" --list_tests_attr
350+
351+
.. note::
352+
This report can be accessed when running KUnit manually by passing in the
353+
module_param ``kunit.action=list_attr``.
354+
355+
Filtering
356+
---------
357+
358+
Users can filter tests using the ``--filter`` command line flag when running
359+
tests. As an example:
360+
361+
.. code-block:: bash
362+
363+
kunit.py run --filter speed=slow
364+
365+
366+
You can also use the following operations on filters: "<", ">", "<=", ">=",
367+
"!=", and "=". Example:
368+
369+
.. code-block:: bash
370+
371+
kunit.py run --filter "speed>slow"
372+
373+
This example will run all tests with speeds faster than slow. Note that the
374+
characters < and > are often interpreted by the shell, so they may need to be
375+
quoted or escaped, as above.
376+
377+
Additionally, you can use multiple filters at once. Simply separate filters
378+
using commas. Example:
379+
380+
.. code-block:: bash
381+
382+
kunit.py run --filter "speed>slow, module=kunit_example_test"
383+
384+
.. note::
385+
You can use this filtering feature when running KUnit manually by passing
386+
the filter as a module param: ``kunit.filter="speed>slow, speed<=normal"``.
387+
388+
Filtered tests will not run or show up in the test output. You can use the
389+
``--filter_action=skip`` flag to skip filtered tests instead. These tests will be
390+
shown in the test output in the test but will not run. To use this feature when
391+
running KUnit manually, use the module param ``kunit.filter_action=skip``.
392+
393+
Rules of Filtering Procedure
394+
----------------------------
395+
396+
Since both suites and test cases can have attributes, there may be conflicts
397+
between attributes during filtering. The process of filtering follows these
398+
rules:
399+
400+
- Filtering always operates at a per-test level.
401+
402+
- If a test has an attribute set, then the test's value is filtered on.
403+
404+
- Otherwise, the value falls back to the suite's value.
405+
406+
- If neither are set, the attribute has a global "default" value, which is used.
407+
408+
List of Current Attributes
409+
--------------------------
410+
411+
``speed``
412+
413+
This attribute indicates the speed of a test's execution (how slow or fast the
414+
test is).
415+
416+
This attribute is saved as an enum with the following categories: "normal",
417+
"slow", or "very_slow". The assumed default speed for tests is "normal". This
418+
indicates that the test takes a relatively trivial amount of time (less than
419+
1 second), regardless of the machine it is running on. Any test slower than
420+
this could be marked as "slow" or "very_slow".
421+
422+
The macro ``KUNIT_CASE_SLOW(test_name)`` can be easily used to set the speed
423+
of a test case to "slow".
424+
425+
``module``
426+
427+
This attribute indicates the name of the module associated with the test.
428+
429+
This attribute is automatically saved as a string and is printed for each suite.
430+
Tests can also be filtered using this attribute.

0 commit comments

Comments
 (0)