linux-kselftest.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Latypov <dlatypov@google.com>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: David Gow <davidgow@google.com>,
	Brendan Higgins <brendanhiggins@google.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"open list:KERNEL SELFTEST FRAMEWORK" 
	<linux-kselftest@vger.kernel.org>,
	Shuah Khan <skhan@linuxfoundation.org>
Subject: Re: [PATCH] lib: add basic KUnit test for lib/math
Date: Thu, 22 Oct 2020 09:26:45 -0700	[thread overview]
Message-ID: <CAGS_qxogKfYBr=5jPsON60NTAoqqSK2y+dQodnZ5r0Uo0ecJ3Q@mail.gmail.com> (raw)
In-Reply-To: <20201022150648.GH4077@smile.fi.intel.com>

On Thu, Oct 22, 2020 at 8:06 AM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Wed, Oct 21, 2020 at 10:47:50AM -0700, Daniel Latypov wrote:
> > On Tue, Oct 20, 2020 at 8:40 PM David Gow <davidgow@google.com> wrote:
> > > On Tue, Oct 20, 2020 at 6:46 AM Daniel Latypov <dlatypov@google.com> wrote:
> > > >
> > > > Add basic test coverage for files that don't require any config options:
> > > > * gcd.c
> > > > * lcm.c
> > > > * int_sqrt.c
> > > > * reciprocal_div.c
> > > > (Ignored int_pow.c since it's a simple textbook algorithm.)
> > > >
> > > I don't see a particular reason why int_pow.c being a simple algorithm
> > > means it shouldn't be tested. I'm not saying it has to be tested by
> > > this particular change -- and I doubt the test would be
> > > earth-shatteringly interesting -- but there's no real reason against
> > > testing it.
> >
> > Agreed on principle, but int_pow() feels like a special case.
> > I've written it the exact same way (modulo variable names+types)
> > several times in personal projects.
> > Even the spacing matched exactly in a few of those...
>
> But if you would like to *teach* somebody by this exemplary piece of code, you
> better do it close to ideal.
>
> > > > These tests aren't particularly interesting, but
> > > > * they're chosen as easy to understand examples of how to write tests
> > > > * provides a place to add tests for any new files in this dir
> > > > * written so adding new test cases to cover edge cases should be easy
> > >
> > > I think these tests can stand on their own merits, rather than just as
> > > examples (though I do think they do make good additional examples for
> > > how to test these sorts of functions).
> > > So, I'd treat this as an actual test of the maths functions (and
> > > you've got what seems to me a decent set of test cases for that,
> > > though there are a couple of comments below) first, and any use it
> > > gains as an example is sort-of secondary to that (anything that makes
> > > it a better example is likely to make it a better test anyway).
> > >
> > > In any case, modulo the comments below, this seems good to me.
> >
> > Ack.
> > I'll wait on Andy's input before deciding whether or not to push out a
> > v2 with the changes.
>
> You need to put detailed comments in the code to have it as real example how to
> create the KUnit test. But hey, it will mean that documentation sucks. So,

Out of curiosity
* By "it will mean that documentation sucks," do you mean that the
documentation will rot faster if people are using the existing in-tree
tests as their entrypoint?
* What level of detailed comments? On the level of kunit-example-test.c?
  * More concretely, then we'd have a comment block linking to the
example and then describing table driven unit testing?
  * And then maybe another block about invariants instead of the
perhaps too-terse /* gcd(a,b) == gcd(b,a) */ ?

> please update documentation to cover issues that you found and which motivated
> you to create these test cases.
>
> Summarize this, please create usable documentation first.

Sounds good.
I'm generally wary people not reading the docs, and of documentation
examples becoming bitrotted faster than actual code.
But so far KUnit seems to be doing relatively well on both fronts.

usage.rst is currently the best place for this, but it felt like it
would quickly become a dumping ground for miscellaneous tips and
tricks.
I'll spend some time thinking if we want a new file or not, based on
how much I want to write about the things this test demonstrated
(EXPECT_*MSG, table driven tests, testing invariants, etc).

In offline discussions with David, the idea had come up with having a
set of (relatively) simple tests in tree that the documentation could
point to as examples of these things. That would keep the line count
in usage.rst down a bit.
(But then it would necessitate more tests like this math_test.c)


>
> --
> With Best Regards,
> Andy Shevchenko
>
>

  reply	other threads:[~2020-10-22 16:26 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-19 22:45 [PATCH] lib: add basic KUnit test for lib/math Daniel Latypov
2020-10-20  0:45 ` kernel test robot
2020-10-20  8:09 ` Andy Shevchenko
2020-10-20 16:13   ` Daniel Latypov
2020-10-21  3:40 ` David Gow
2020-10-21 17:47   ` Daniel Latypov
2020-10-22 15:06     ` Andy Shevchenko
2020-10-22 16:26       ` Daniel Latypov [this message]
2020-10-22 18:51         ` Brendan Higgins
2020-10-22 19:10         ` Andy Shevchenko
2020-10-22 19:12           ` Andy Shevchenko
2020-10-22 18:53       ` Brendan Higgins
2020-10-22 19:05         ` Andy Shevchenko
2020-10-22 21:21           ` Brendan Higgins
2020-10-23  9:02             ` Andy Shevchenko
2020-11-02 14:51 ` kernel test robot
2020-11-03  1:32 ` kernel test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAGS_qxogKfYBr=5jPsON60NTAoqqSK2y+dQodnZ5r0Uo0ecJ3Q@mail.gmail.com' \
    --to=dlatypov@google.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=brendanhiggins@google.com \
    --cc=davidgow@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=skhan@linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).