tools/testing/selftests/tc-testing/creating-testcases/AddingTestCases.txt

Source file repositories/reference/linux-study-clean/tools/testing/selftests/tc-testing/creating-testcases/AddingTestCases.txt

File Facts

System
Linux kernel
Corpus path
tools/testing/selftests/tc-testing/creating-testcases/AddingTestCases.txt
Extension
.txt
Size
5019 bytes
Lines
108
Domain
Support Tooling And Documentation
Bucket
tools
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

tdc - Adding test cases for tdc

Author: Lucas Bates - lucasb@mojatatu.com

ADDING TEST CASES
-----------------

User-defined tests should be added by defining a separate JSON file.  This
will help prevent conflicts when updating the repository. Refer to
template.json for the required JSON format for test cases.

Include the 'id' field, but do not assign a value. Running tdc with the -i
option will generate a unique ID for that test case.

tdc will recursively search the 'tc-tests' subdirectory (or the
directories named with the -D option) for .json files.  Any test case
files you create in these directories will automatically be included.
If you wish to store your custom test cases elsewhere, be sure to run
tdc with the -f argument and the path to your file, or the -D argument
and the path to your directory(ies).

Be aware of required escape characters in the JSON data - particularly
when defining the match pattern. Refer to the supplied json test files
for examples when in doubt.  The match pattern is written in json, and
will be used by python.  So the match pattern will be a python regular
expression, but should be written using json syntax.


TEST CASE STRUCTURE
-------------------

Each test case has required data:

id:           A unique alphanumeric value to identify a particular test case
name:         Descriptive name that explains the command under test
skip:         A completely optional key, if the corresponding value is "yes"
              then tdc will not execute the test case in question. However,
              this test case will still appear in the results output but
              marked as skipped. This key can be placed anywhere inside the
              test case at the top level.
dependsOn:    Same as 'skip', but the value is executed as a command. The test
              is skipped when the command returns non-zero.
category:     A list of single-word descriptions covering what the command
              under test is testing. Example: filter, actions, u32, gact, etc.
setup:        The list of commands required to ensure the command under test
              succeeds. For example: if testing a filter, the command to create
              the qdisc would appear here.
	      This list can be empty.
	      Each command can be a string to be executed, or a list consisting
	      of a string which is a command to be executed, followed by 1 or
	      more acceptable exit codes for this command.
	      If only a string is given for the command, then an exit code of 0
	      will be expected.
cmdUnderTest: The tc command being tested itself.
expExitCode:  The code returned by the command under test upon its termination.
              tdc will compare this value against the actual returned value.
verifyCmd:    The tc command to be run to verify successful execution.
              For example: if the command under test creates a gact action,
              verifyCmd should be "$TC actions show action gact"
matchPattern: A regular expression to be applied against the output of the
              verifyCmd to prove the command under test succeeded. This pattern
              should be as specific as possible so that a false positive is not
              matched.
matchCount:   How many times the regex in matchPattern should match. A value
              of 0 is acceptable.
teardown:     The list of commands to clean up after the test is completed.
              The environment should be returned to the same state as when
              this test was started: qdiscs deleted, actions flushed, etc.
	      This list can be empty.
	      Each command can be a string to be executed, or a list consisting

Annotation

Implementation Notes