• Home
Name Date Size #Lines LOC

..--

mkosi/03-May-2024-11894

module-playground/03-May-2024-643478

rootfs-pristine/03-May-2024-477308

.gitignoreD03-May-2024895 5857

COPYINGD03-May-202425.8 KiB505418

MakefileD03-May-2024372 167

READMED03-May-20242.5 KiB6245

delete_module.cD03-May-20243.5 KiB169115

init_module.cD03-May-20248.2 KiB404289

path.cD03-May-20244.8 KiB206159

populate-modules.shD03-May-20245.5 KiB11597

stripped-module.hD03-May-2024520 3019

test-array.cD03-May-20245.2 KiB202147

test-blacklist.cD03-May-20242.5 KiB10669

test-dependencies.cD03-May-20242.2 KiB9056

test-depmod.cD03-May-20246.1 KiB213178

test-hash.cD03-May-20246.5 KiB283199

test-init.cD03-May-20243.2 KiB13293

test-initstate.cD03-May-20243.1 KiB12786

test-list.cD03-May-20245.9 KiB239163

test-loaded.cD03-May-20242.3 KiB9261

test-modinfo.cD03-May-20243.3 KiB12394

test-modprobe.cD03-May-202410.5 KiB420362

test-new-module.cD03-May-20242.7 KiB11984

test-scratchbuf.cD03-May-20243.1 KiB9053

test-strbuf.cD03-May-20242.6 KiB9963

test-testsuite.cD03-May-20243.5 KiB164118

test-tools.cD03-May-20241.8 KiB7248

test-util.cD03-May-20245.3 KiB230179

testsuite.cD03-May-202423.5 KiB1,123899

testsuite.hD03-May-20245.3 KiB188104

uname.cD03-May-20241.8 KiB7545

README

1testsuite
2
3OVERVIEW
4========
5
6Kmod's testsuite was designed to automate the process of running tests with
7different scenarios, configurations and architectures. The idea is that once we
8received a bug report, we reproduce it using the testsuite so we avoid
9recurring on the same bug in future.
10
11
12FEATURES
13========
14
15- Isolate each test by running them in separate processes;
16- Exec a binary, so we can test the tools and not only the lib API
17- Fake accesses to filesystem so we can provide a test rootfs with all the
18  configuration, indexes, etc that test needs to be executed.
19- Fake calls to init_module(), delete_module() and uname(), so we don't have to
20  run tests as root and figure out how to deal with different architectures.
21
22HOW TO ADD A TEST
23=================
24
25The simplest way to add a test is to copy and paste one already there. Most of
26the options you can have are covered by another tests. This is what you need to
27pay attention when writing a test:
28
291 - Look at testsuite.h, struct test, to see all the options available.
30
312 - Use TESTSUITE_MAIN and DEFINE_TEST to add new tests. Don't forget to fill
32    its description.
33
343 - If you want testsuite to compare the stdout/stderr of your tests in order
35    to check if it worked or not, fill in output.{stderr,stdout} the file with
36    the expected output. Bear in mind the same file is used for all
37    architectures, so don't print arch-dependent content if you are comparing
38    the output.
39
404 - Fill in the config vector. Setting any of these configuration will make
41    testsuite to export LD_PRELOAD with the necessary override libs before
42    executing the test. If you are not exec'ing an external binary, you need to
43    pass "need_spawn = true" below, otherwise it will not work (LD_PRELOAD is
44    only applied when exec'ing a binary). See each config description in
45    testsuite.h
46
475 - need_spawn: if testsuite will exec itself before running a test
48
496 - expected_fail: if that test is expected to fail, i.e. the return code is
50    expected not to be 0.
51
527 - The rootfs is populated by copying the entire contents of rootfs-pristine
53    then running populate-modules.sh to copy generated modules from
54    module-playground. Update the latter script to include any modules your
55    test need.
56
578 - Tests can be run individually, outside of 'make check'. strace and gdb work
58    too, as long as you tell them to operate on child process.
59
609 - Make sure test passes when using "default" build flags, i.e. by running
61    'autogen.sh c'
62