[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAGS_qxr0=nvQb787SURuVN7G-M9BdMR800FtwR3YAkFxQgPf5w@mail.gmail.com>
Date: Fri, 9 Apr 2021 09:29:10 -0700
From: Daniel Latypov <dlatypov@...gle.com>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc: Brendan Higgins <brendanhiggins@...gle.com>,
David Gow <davidgow@...gle.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
KUnit Development <kunit-dev@...glegroups.com>,
"open list:KERNEL SELFTEST FRAMEWORK"
<linux-kselftest@...r.kernel.org>,
Shuah Khan <skhan@...uxfoundation.org>
Subject: Re: [PATCH v4] lib: add basic KUnit test for lib/math
On Fri, Apr 9, 2021 at 8:30 AM Andy Shevchenko
<andriy.shevchenko@...ux.intel.com> wrote:
>
> On Thu, Apr 08, 2021 at 06:40:01PM -0700, Daniel Latypov 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.)
>
> What about adding math.h test cases?
>
> We have some macros there and it might be a good idea to test them, for example
> that round_up() and roundup() produces the same output for the same (power of
> two divisor) input.
I completely overlooked the macros in math.h, sounds like a good idea.
Grepping around, seems like abs() and DIV_ROUND_UP/CLOSEST() are among
the more popular macros:
$ ag -s '\bDIV_ROUND_UP\(' | wc -l
2946
$ ag -s '\babs\(' | wc -l
923
$ ag -s '\bDIV_ROUND_CLOSEST\(' | wc -l
864
$ ag -s '\bround_up\(' | wc -l
727
$ ag -s '\broundup\(' | wc -l
620
$ ag -s '\bround_down\(' | wc -l
371
$ ag -s 'rounddown\(' | wc -l
131
>
> > These tests aren't particularly interesting, but they
> > * provide short and simple examples of parameterized tests
> > * provide a place to add tests for any new files in this dir
> > * are written so adding new test cases to cover edge cases should be easy
>
> Yes, that's why I think macros also can be a good example how to test *macro*.
Yeah, there's more to cover there since they have a range of types
they can work on.
On another note, the parameterized test arrays all use unsigned long,
so abs() sticks out even more.
I'm thinking of something like
static void test_abs(struct kunit *test)
{
KUNIT_EXPECT_EQ(test, abs('a'), 'a');
KUNIT_EXPECT_EQ(test, abs(-'a'), 'a');
...
}
and then maybe use parameters for the other macros but also throw in
an additional test case like
static void test_div_round_up_diff_types(struct kunit *test)
{
KUNIT_EXPECT_EQ(test, DIV_ROUND_UP((char) 42, (char) 10), (char) 4);
KUNIT_EXPECT_EQ(test, DIV_ROUND_UP((int) 42, (int) 10), (int) 4);
KUNIT_EXPECT_EQ(test, DIV_ROUND_UP((long) 42, (long) 10), (long) 4);
...
}
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
> --
> You received this message because you are subscribed to the Google Groups "KUnit Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to kunit-dev+unsubscribe@...glegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/kunit-dev/YHBzA7SwH194ywRv%40smile.fi.intel.com.
Powered by blists - more mailing lists