Documentation/dev-tools/kunit/style.rst

Source file repositories/reference/linux-study-clean/Documentation/dev-tools/kunit/style.rst

File Facts

System
Linux kernel
Corpus path
Documentation/dev-tools/kunit/style.rst
Extension
.rst
Size
8736 bytes
Lines
214
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: documentation
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

.. SPDX-License-Identifier: GPL-2.0

===========================
Test Style and Nomenclature
===========================

To make finding, writing, and using KUnit tests as simple as possible, it is
strongly encouraged that they are named and written according to the guidelines
below. While it is possible to write KUnit tests which do not follow these rules,
they may break some tooling, may conflict with other tests, and may not be run
automatically by testing systems.

It is recommended that you only deviate from these guidelines when:

1. Porting tests to KUnit which are already known with an existing name.
2. Writing tests which would cause serious problems if automatically run. For
   example, non-deterministically producing false positives or negatives, or
   taking a long time to run.

Subsystems, Suites, and Tests
=============================

To make tests easy to find, they are grouped into suites and subsystems. A test
suite is a group of tests which test a related area of the kernel. A subsystem
is a set of test suites which test different parts of a kernel subsystem
or a driver.

Subsystems
----------

Every test suite must belong to a subsystem. A subsystem is a collection of one
or more KUnit test suites which test the same driver or part of the kernel. A
test subsystem should match a single kernel module. If the code being tested
cannot be compiled as a module, in many cases the subsystem should correspond to
a directory in the source tree or an entry in the ``MAINTAINERS`` file. If
unsure, follow the conventions set by tests in similar areas.

Test subsystems should be named after the code being tested, either after the
module (wherever possible), or after the directory or files being tested. Test
subsystems should be named to avoid ambiguity where necessary.

If a test subsystem name has multiple components, they should be separated by
underscores. *Do not* include "test" or "kunit" directly in the subsystem name
unless we are actually testing other tests or the kunit framework itself. For
example, subsystems could be called:

``ext4``
  Matches the module and filesystem name.
``apparmor``
  Matches the module name and LSM name.
``kasan``
  Common name for the tool, prominent part of the path ``mm/kasan``
``snd_hda_codec_hdmi``
  Has several components (``snd``, ``hda``, ``codec``, ``hdmi``) separated by
  underscores. Matches the module name.

Avoid names as shown in examples below:

``linear-ranges``
  Names should use underscores, not dashes, to separate words. Prefer
  ``linear_ranges``.
``qos-kunit-test``
  This name should use underscores, and not have "kunit-test" as a
  suffix. ``qos`` is also ambiguous as a subsystem name, because several parts
  of the kernel have a ``qos`` subsystem. ``power_qos`` would be a better name.
``pc_parallel_port``
  The corresponding module name is ``parport_pc``, so this subsystem should also
  be named ``parport_pc``.

.. note::

Annotation

Implementation Notes