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]
--
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/apparmor
