mirror of
https://github.com/AuxXxilium/kmod.git
synced 2024-11-24 07:20:52 +07:00
cdbcc2481c
The current configuration is dumb in any number of ways: 1) If the rationale was for space savings, it works the opposite- the git repo gets more bloated because we are adding binary compressed blobs that share little in common with their parent, and anyone that wants to run the test suite has to unzip it anyway. 2) It is a pain in the butt to add new tests, and not accidentally lose any new rootfs you built in the directory. 3) `git status` won't help you if you are tweaking files in the rootfs and don't know they have been changed, or if some test did that and you couldn't detect it. 4) `git log` won't help you find out what is changing in the rootfs test directory itself when changes are made to the binary blob, such as new files being added or even existing files being tweaked. 5) The files just aren't that big anyway- 2.7MB unzipped. |
||
|---|---|---|
| .. | ||
| rootfs | ||
| .gitignore | ||
| delete_module.c | ||
| init_module.c | ||
| path.c | ||
| README | ||
| stripped-module.h | ||
| test-alias.c | ||
| test-init.c | ||
| test-loaded.c | ||
| test-modinfo.c | ||
| test-modprobe.c | ||
| test-new-module.c | ||
| test-testsuite.c | ||
| testsuite.c | ||
| testsuite.h | ||
| uname.c | ||
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. Bare 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. If you are not exec'ing an external binary, you need to
pass "need_spawn = true" below, otherwise it will not work (LD_PRELOAD is
only applied when exec'ing a binary). See each config description in
testsuite.h
5 - need_spawn: if testsuite will exec itself before running a test
6 - expected_fail: if that test is expected to fail, i.e. the return code is
expected not to be 0.
7 - If you added files to the rootfs, be sure to compact it back to
rootfs.tar.xz before sending patches: use 'make testsuite-pack-rootfs'
8 - Tests can be run individually, outside of 'make check'. strace and gdb work
too, as long as you tell them to operate on child process.
9 - Make sure test passes when using "default" build flags, i.e. by running
bootstrap-configure instead of simpler bootstrap/autogen.sh