-
Notifications
You must be signed in to change notification settings - Fork 9
Guidance for test authors
This document mostly applies to Python tests but some of the guidance may be more broadly applicable.
Each test directory has a config
file listing which kernel
configuration options the tests depend on. This file must be kept
up to date, our CIs build minimal kernels for each test group.
Adding checks inside the tests to validate that the necessary kernel configs are enabled is discouraged. The test author may include such checks, but standalone patches to make tests compatible e.g. with distro kernel configs are unlikely to be accepted.
Test files should be relatively self contained. The libraries should only include very core or non-trivial code. It may be tempting to "factor out" the common code, but fight that urge. Library code increases the barrier of entry, and complexity in general.
Similarly to the previous point, in Python, try to avoid adding code in the main()
function which instantiates NetDrvEnv()
and calls ksft_run()
. It's okay to set up global resources (e.g. open an RtNetlink socket used by multiple tests), but any complex logic, test-specific environment configuration and validation should be done in the tests (even if it means it has to be repeated).
Dual-host tests (tests with an endpoint) should be written from the DUT perspective. IOW the local machine should be the one tested, remote is just for traffic generation and may be shared.
Try not to make configuration changes to the remote system.
The env must be clean after test exits. Register a defer() for any action that needs an "undo" as soon as possible. If you need to run the cancel action as part of the test - defer returns an object you can execute.
Use ksft_pr()
instead of print()
to avoid breaking TAP format.
By default the tests are expected to be able to run on a single-interface systems. All tests which may disconnect NETIF
must be annotated with @ksft_disruptive
.