mirror of
https://gitlab.com/apparmor/apparmor.git
synced 2025-03-04 08:24:42 +01:00
![]() [previous commit forgot to bzr add caching.py; this commit fixes that] This patch rewrites the caching test in python, using python's unittest framework. It has been used with python 2.7 and python 3.3; python2.6 may have issues. It covers the tests in the existing caching.sh test script (with the exception of the test that checks for when the parser in $PATH is newer), as well as adding additional tests that more extensively cover using a cache in an alternate location from basedir. It also adds simple tests for the --create-cache-dir option (along with that option's interaction with the alt-cache option). (Some further work to be done is listed under TODO.) Patch history: v1: - initial version v2: - create template base class - add keep_on_fail() decorator to keep temporary test files around after a test fails - don't dump raw cache file to failure output in test_cache_writing_updates_cache_file() - push run_cmd into template class - create run_cmd_check wrapper to run_cmd that adds an assertion check based on whether return code matches the expected rc (the valgrind tests only want to verify that the rc is not a specific set of values, hence the separate wrapper function) - similarly, add a check to run_cmd_check for verifying the output contains a specific string, also simplifying many of the caching tests. - create testlib.write_file() to simplify writing file Signed-off-by: Steve Beattie <steve@nxnw.org> Acked-by: Christian Boltz <apparmor@cboltz.de> |
||
---|---|---|
.. | ||
errors | ||
simple_tests | ||
caching.profile | ||
caching.py | ||
caching.sh | ||
equality.sh | ||
gen-dbus.pl | ||
gen-xtrans.pl | ||
Makefile | ||
minimize.sh | ||
README | ||
simple.pl | ||
testlib.py | ||
uservars.conf | ||
valgrind_simple.py |
This is the README for the AppArmor parser regression testsuite. Running the testsuite --------------------- Running the tests is pretty easy, a simple 'make tests' should make it go, assuming the subdomain parser and perl are installed. There is a user configuration file 'uservars.conf'. If you wish to test against a different parser, or use a different set of profiles for the simple.pl test, you can change those settings in 'uservars.conf'. You can also override which parser is used through make by specifying the PARSER veriable. For example, to run the tests on the system parser, run 'make PARSER=/sbin/apparmor_parser'. Adding to the testsuite ----------------------- The testsuite currently contains one testscript (simple.pl) and makes use of perl's Test::Simple, Test::Harness, and prove utilities (see 'perldoc Test::Tutorial', 'perldoc Test::Simple', 'perldoc Test::Harness', and 'man 1 prove' for more information on these). It should be relatively easy to extend the suite with other testscripts, as long as they're written using Test::Simple or can emulate the Test::Harness protocol. To add a script, add it to the TESTS variable in the Makefile, and it will included in the tests to be run. However, in many cases, it is not necessary to add an entire new testscript for a testcase. Instead, the simple testcase (see below) will run all the profiles it finds on the parser, thus adding testcases is usually as simple as writing a new profile with a couple of extra comments. Simple parsing tests (simple.pl) -------------------------------- This test script tests the parser front end's ability to identify legal profiles. It does this by running the parser against several legal and illegal profiles (in debug mode, so as not to load them into the module proper) The simple script has the parser attempt to parse all of the profiles named *.sd in the simple_tests/ subdirectory; thus, to add a new profile to test, simply add it to the simple_tests/ directory. The simple script also adds the testdir (simple_tests/ by default) to the parsers include path (assuming that particular bug has been fixed :-)). There is an includes/ subdir to place additional includes if necessary (we purposefully choose to use different directory names versus the shipped profiles to minimize testsuite breakage with changes in the external policy). The simple script looks for a few special comments in the profile, #=DESCRIPTION, #=EXRESULT, and #=TODO: - #=DESCRIPTION -- all text following the keyword is considered a description for the test. Please try to make these meaningful. - #=EXRESULT -- This records the expected result of parsing this profile. Values can either be PASS or FAIL; if no comment is found that matches this pattern, then the profile is assumed to have an expected parse result of PASS. - #=TODO -- marks the test as being for a future item to implement and thus are expected testsuite failures and hsould be ignored. - #=DISABLED -- skips the test, and marks it as a failed TODO task. Useful if the particular testcase causes the parser to infinite loop or dump core. Otherwise, the profile is passed on as-is to the subdomain parser.