linux-kernel - Re: [PATCH linux-kselftest/test v1] apparmor: add AppArmor KUnit tests for policy unpack

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 30 Oct 2019 18:40:03 -0700
From:   John Johansen <john.johansen@...onical.com>
To:     Iurii Zaikin <yzaikin@...gle.com>,
        Kees Cook <keescook@...omium.org>
Cc:     Luis Chamberlain <mcgrof@...nel.org>,
        Brendan Higgins <brendanhiggins@...gle.com>,
        Alan Maguire <alan.maguire@...cle.com>,
        Matthias Maennich <maennich@...gle.com>,
        shuah <shuah@...nel.org>, jmorris@...ei.org, serge@...lyn.com,
        David Gow <davidgow@...gle.com>, Theodore Ts'o <tytso@....edu>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-security-module@...r.kernel.org,
        KUnit Development <kunit-dev@...glegroups.com>,
        "open list:KERNEL SELFTEST FRAMEWORK" 
        <linux-kselftest@...r.kernel.org>,
        Mike Salvatore <mike.salvatore@...onical.com>
Subject: Re: [PATCH linux-kselftest/test v1] apparmor: add AppArmor KUnit
 tests for policy unpack

On 10/30/19 1:11 PM, Iurii Zaikin wrote:
>> Why can't unit tests live with the code they're testing? They're already
>> logically tied together; what's the harm there? This needn't be the case
>> for ALL tests, etc. The test driver could still live externally. The
>> test in the other .c would just have exported functions... ?
>>
> Curiously enough, this approach has been adopted by D 2.0 where unittests are
> members of the class under test:  https://digitalmars.com/d/2.0/unittest.html
> but such approach is not mainstream.
> I personally like the idea of testing the lowest level bits in isolation even if
> they are not a part of any interface. I think that specifying the
> interface using
> unit tests and ensuring implementation correctness are complementary but

fwiw this is my preferred approach as well

> I haven't had much luck arguing this with our esteemed colleagues.
> 

surprise, surprise /s