[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <81d04cb1-057d-10bd-1c40-80aa2c26fe62@canonical.com>
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
Powered by blists - more mailing lists