apparmor/parser/tst
John Johansen 419d82c13b libapparmor: handle feature hash collision by falling back to next dir
Adjust the cache directory name from
  <cache_loc>/<feature_id>
to
  <cache_loc>/<feature_id>.<n>

where <n> is 0 for the first cache created for a given feature_id.
If there is a feature_id collision then <n> will be incremented to
the next number.

The .features file within each cache directory is used to disambiguate
which feature_id cache dir belongs to which feature set.

Cache collisions and missing caches cause a slow path that searches
existing cache dirs that fit the cache_name pattern, to ensure the
proper dir is chosen.

TODO: add regression tests
  create cache dir  check it
  copy different feature set to it
  create cache dir again, check it, check that it incremented...

Signed-off-by: John Johansen <john.johansen@canonical.com>
Acked-by: Christian Boltz <apparmor@cboltz.de>
2018-04-14 15:51:23 -07:00
..
errors as ACKed on IRC, drop the unused $Id$ tags everywhere 2010-12-20 12:29:10 -08:00
features_files parser: Update features.all file for new kernel features 2016-03-19 03:03:18 -05:00
simple_tests parser: add support for conditional includes 2018-01-20 00:32:20 -08:00
caching.profile actually add caching tests 2009-11-11 11:07:50 -08:00
caching.py libapparmor: handle feature hash collision by falling back to next dir 2018-04-14 15:51:23 -07:00
equality.sh Fix: make sure overlapping safe and unsafe exec rules conflict 2016-06-02 22:24:22 -07:00
gen-dbus.pl parser: Test dbus eavesdrop rule parsing 2013-12-06 11:18:48 -08:00
gen-xtrans.pl Description: Improve generated test readability and build-time cleanup. 2011-05-02 13:36:55 -07:00
Makefile all: Use the MAKE variable 2017-11-01 23:22:53 +00:00
minimize.sh Hack rework of the feature/match file support 2014-04-23 10:53:46 -07:00
mk_features_file.py parser language tests: force using a features file 2014-04-24 12:14:54 -07:00
README parser: Detect core dumps during parser tests 2013-09-11 11:56:47 -07:00
simple.pl Raise the self-test timeout to 4 minutes for really slow machines. 2017-10-23 15:28:48 +02:00
testlib.py parser: Don't skip cleanup when the test was skipped 2015-08-18 10:59:21 -05:00
uservars.conf as ACKed on IRC, drop the unused $Id$ tags everywhere 2010-12-20 12:29:10 -08:00
valgrind_simple.py parser: fix equality and valgrind test scripts to use features file 2015-03-19 04:35:08 -07:00

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.