[apparmor] [patch] parser/tst/simple_tests/profile/flags/* - remove or replace #include lines

Christian Boltz apparmor at cboltz.de
Fri Aug 15 19:55:25 UTC 2014


Hello,

Am Dienstag, 12. August 2014 schrieb Steve Beattie:
> On Wed, Aug 06, 2014 at 10:45:55PM +0200, Christian Boltz wrote:
> > the test profiles in parser/tst/simple_tests/profile/flags/* contain
> > 
> >   #include <includes/base>
> > 
> > which doesn't exist.
> 
> Except that it does, as parser/tst/simple_tests/includes/base. The
> simple.pl script [1] adds parser/tst/simple_tests/ as an include dir.

Ah, that's the missing detail ;-)

I just wanted to test the test profiles related to flags, and therefore 
didn't notice how the tests are typically run ;-)

> The path was explicitly chosen to not align with abstractions/base,
> to ensure that test results wouldn't differ depending on whether
> abstractions/base has been installed into a system location or not.

Sounds like a good idea to avoid side effects.
(I'd have chosen a more obvious directory name like "test_inc/" ;-)

> > Instead of changing it to abstractions/, it's better to completely
> > remove the #include line. Those tests are for testing flags, not
> > include files ;-)
> 
> On the one hand, that's entirely correct. On the other, we do want
> to ensure there's no weird interactions between parsing flags and the
> rest of a complex profile, but that should probably be the exception
> rather than the rule. So on the whole, I'm okay with this patch.
> 
> Acked-by: Steve Beattie <steve at nxnw.org>

Now that I know that includes/base actually exists, and I just failed to 
run the tests in the correct/expected way, I think I should only commit 
parts of my patch.

The flags_ok*.sd tests should be kept unchanged - if they fail for 
whatever reason (including "weird interactions between parsing flags and 
the rest of a complex profile"), then this is a bug and should be 
catched by the tests.

OTOH, I'd like to commit my changes to the flags_bad*.sd tests - they 
are expected to fail. I'd prefer if each of them only contains exactly 
one reason for failure - that ensures that we notice it if they 
suddently don't fail anymore. This means the flags_bad*.sd tests [1] 
have to be as simple as possible.

Do you agree with only commiting my flags_bad*.sd changes?


Regards,

Christian Boltz

[1] well, actually all *_bad*.sd tests should be as simple as possible 
    ;-)
-- 
wie jeder weiß ist Debian auf ISDN die langsamste bekannte Methode
Selbstmord zu begehen ("Selbstmord durch Erosion")
[http://blog.koehntopp.de/archives/113-Debian-ist-doch-schlecht..html]




More information about the AppArmor mailing list