[apparmor] [patch 2/3] Add tests for NetworkRule and NetworkRuleset

[Christian Boltz]

Hello,

Am Montag, 20. April 2015 schrieb Kshitij Gupta:
> On Mon, Apr 20, 2015 at 3:59 AM, Christian Boltz wrote:
> > Am Sonntag, 19. April 2015 schrieb Kshitij Gupta:
> > > On Sat, Apr 18, 2015 at 2:51 AM, Christian Boltz wrote:

> > Hmm, that's an interesting question.
> > 
> > While I agree that those rules make sense for "normal" code, I'm not
> > sure if they make sense for our testcases.
> > 
> > Basically the order I'm using is:
> >     1. libraries needed to setup and run the tests (sooner or later,
> >     all
> >     
> >        tests will have those imports)
> >     
> >     2. the things we want to test
> >     3. additional libs needed for some tests (for example 're', even
> >     if
> >     
> >        that vanished by moving test_parse_profile_invalid() to
> >        test-baserule.py)
> > 
> I'm find with this reasoning for not following the PEP 8.
> 
> It'll be interesting to see what a pyflakes run says about it.

;-)

> > > As stated in rule/__init__.py, subclasses needed to implement
> > > get_clean so its fair that get_clean should have tests here,
> > > however,
> > > get_raw is not being implemented in capability or network rule
> > > classes and it seems redundant to have tests for the same at both
> > > places. I feel we can do away with tests for these methods in
> > > every
> > > rule class and have them centralised place (tests for the __init__
> > > stuff), unless a class overrides it. Opinions?
> > 
> > In theory, I agree - yes, it seems redundant.
> > 
> > In practise, I want to keep that safety net - and I also want to
> > test
> > with all rule types to make sure we don't accidently break writing
> > the raw rule somewhere.
> > 
> Its okay I guess until we start having too much redundant tests(if
> there's such a thing) for safety.

There is nothing like "too much tests" ;-)

Test code is (more or less) fire-and-forget. As long as all tests 
succeed, I don't care too much about duplicated code [1], "superfluous" 
tests etc. Nevertheless it doesn't hurt if the test code is easy to read 
and understand, that's why I introduced the tests[] loop and now 
namedtuple. 

Oh, and if one of those "superfluous" tests fails, I'm happy to have it.

Writing test-network.py (including the "superfluous" tests) took some 
hours. OTOH, I remember cases where I needed several hours to hunt down 
_one_ bug (in code without test coverage), so it definitively pays out 
to "waste" an hour to write some superfluous tests ;-)


Regards,

Christian Boltz

[1] I'll tell you something totally different when it comes to the 
    "real" code ;-)

-- 
Wenn ich eine SuSE-CD an ein Schwein binde und dieses trete, laufen
KDE & Co. auch ohne RAM recht schnell.
                 [Robin S. Socha in de.comp.os.unix.linux.newusers]