linux-ext4 - Re: [PATCH linux-kselftest/test v2] ext4: add kunit test for decoding extended timestamps

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:   Thu, 17 Oct 2019 17:11:32 -0700
From:   Iurii Zaikin <yzaikin@...gle.com>
To:     "Bird, Timothy" <Tim.Bird@...y.com>
Cc:     Shuah Khan <skhan@...uxfoundation.org>,
        "Theodore Ts'o" <tytso@....edu>,
        Brendan Higgins <brendanhiggins@...gle.com>,
        "open list:KERNEL SELFTEST FRAMEWORK" 
        <linux-kselftest@...r.kernel.org>, linux-ext4@...r.kernel.org,
        adilger.kernel@...ger.ca,
        KUnit Development <kunit-dev@...glegroups.com>
Subject: Re: [PATCH linux-kselftest/test v2] ext4: add kunit test for decoding
 extended timestamps

On Thu, Oct 17, 2019 at 4:54 PM <Tim.Bird@...y.com> wrote:
>
>
>
> > -----Original Message-----
> > From: Iurii Zaikin
> >
> > > You can do all of this and allow users to supply another set of data.
> > > It doesn't gave to be one or the other.
> > >
> > What is the use case for running a unit test on a different data set than
> > what it comes with?
>
> I just gave some ideas in another message (our emails crossed),
> but one use case is to allow someone besides the test author
> to inject additional data points, and to do so without having to re-compile
> the code.
>
> They might do this for multiple reasons:
>  - to experiment with additional data points
>  - to try to diagnose a problem they are seeing
>  - to fill gaps they see in existing data points
>
> Whether this makes sense depends on a lot of factors.  I suspect
> the timestamp test code is not a good candidate for this, as the code
> is simple enough that adding a new test case is pretty trivial.  For some
> other types of tests, adding the data via an external file could be easier
> than changing the code of the test.

I think feeding test data without recompiling looks attractive right now because
in order to run a single test you need to compile and link the whole kernel.
I believe KUnit's strategic goal is the ability to only compile the
relevant bits,
which is admittedly very far off.
Normally, in application programming the amount of code that needs to be
recompiled in order to run a test suite is small enough that the added
complexity
of enabling the test to get the data from external sources is not
warranted. Typically,
external files are used when something is not practical to include in
the source file
directly due to size or complexity, i.e. a large snippet of text, an
image file, some
binary data etc. Such needs are typically addressed by the test author
rather than
the core test framework.
Now, in application programming you can do a lot of things like
reading a file which
is trickier in kernel. But again we've come to supporting a use case
for test data which
has to be fabricated through some involved process or otherwise not
easily included
in the source file.
And if you come up with an additional test case, why not just add it
and leave it there?
Unit tests are cheap, even if a case proves to be redundant, the mere
fact that the
code under test made you think of such a case is sufficient to
permanently include
the test case into the test suite.