mirror of
https://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git
synced 2024-11-23 10:53:40 +08:00
c5c36b61da
Our test suite is a little unique in my experience in that the test can be either a normal (fork) child or a (re)spawned one. All the other test frameworks I have used opt for only one of the two. I'm not entirely sure why we have both since the latter is sufficient for all use-cases that we have. Perhaps the former was kept as micro-optimisation? Currently I am exploring a way to provide the results summary and the need_spawn = false ones, are printed multiple times. At a glance I couldn't quite find a way to fix it. In addition I am also looking at removing/reducing the use of exit() across the test suite. Where the two code-flows makes that process more convoluted. So let's remove one of the code-paths, simplify things and fix the logging output. If needed we can re-introduce it later on. NOTE: there's a lot going on here, because clang-format insist on reformatting bunch of the DEFINE_TEST() instances :-\ Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Link: https://github.com/kmod-project/kmod/pull/246 Signed-off-by: Lucas De Marchi <lucas.de.marchi@gmail.com>
61 lines
2.5 KiB
Plaintext
61 lines
2.5 KiB
Plaintext
testsuite
|
|
|
|
OVERVIEW
|
|
========
|
|
|
|
Kmod's testsuite was designed to automate the process of running tests with
|
|
different scenarios, configurations and architectures. The idea is that once we
|
|
received a bug report, we reproduce it using the testsuite so we avoid
|
|
recurring on the same bug in future.
|
|
|
|
|
|
FEATURES
|
|
========
|
|
|
|
- Isolate each test by running them in separate processes;
|
|
- Exec a binary, so we can test the tools and not only the lib API
|
|
- Fake accesses to filesystem so we can provide a test rootfs with all the
|
|
configuration, indexes, etc that test needs to be executed.
|
|
- Fake calls to init_module(), delete_module() and uname(), so we don't have to
|
|
run tests as root and figure out how to deal with different architectures.
|
|
|
|
HOW TO ADD A TEST
|
|
=================
|
|
|
|
The simplest way to add a test is to copy and paste one already there. Most of
|
|
the options you can have are covered by another tests. This is what you need to
|
|
pay attention when writing a test:
|
|
|
|
1 - Look at testsuite.h, struct test, to see all the options available.
|
|
|
|
2 - Use TESTSUITE_MAIN and DEFINE_TEST to add new tests. Don't forget to fill
|
|
its description.
|
|
|
|
3 - If you want testsuite to compare the stdout/stderr of your tests in order
|
|
to check if it worked or not, fill in output.{stderr,stdout} the file with
|
|
the expected output. Bear in mind the same file is used for all
|
|
architectures, so don't print arch-dependent content if you are comparing
|
|
the output.
|
|
|
|
4 - Fill in the config vector. Setting any of these configuration will make
|
|
testsuite to export LD_PRELOAD with the necessary override libs before
|
|
executing the test. See each config description in testsuite.h
|
|
|
|
5 - expected_fail: if that test is expected to fail, i.e. the return code is
|
|
expected not to be 0.
|
|
|
|
6 - The rootfs is populated by copying the entire contents of rootfs-pristine
|
|
through setup-rootfs.sh then running setup-modules.sh to copy generated
|
|
modules from module-playground. Update the latter script to include any
|
|
modules your test needs.
|
|
|
|
7 - Tests can be run individually, outside of 'meson test'. strace and gdb
|
|
work too, as long as you tell them to operate on child process.
|
|
|
|
When running with sanitizers, make sure to 'source scripts/sanitizer-env.sh'.
|
|
Sanitizers are not guaranteed to work well with other tools like strace and gdb.
|
|
|
|
8 - Make sure test passes when using "default" build flags, i.e. by running
|
|
'meson setup --native-file build-dev.ini ...', which by default enables the
|
|
sanitizers.
|