Quoting Daniel Latypov (2022-01-20 13:56:39)
> On Thu, Jan 20, 2022 at 1:31 PM Stephen Boyd <sboyd@xxxxxxxxxx> wrote:
> > I was thinking this would be more generic so that one file tests clk.c
> > and all the code in there, but I guess there may be config dependencies
> > like CONFIG_OF that we may want to extract out and depend on
> > differently. I'm not sure how kunit will handle testing different paths
> > depending on build configuration so this approach may head off future
> > problems. If it doesn't then we can always slam the test together.
>
> KUnit doesn't have hard technical limitations in this regard.
>
> You could have something like this
>
> static void my_optional_kunit_test(struct kunit *test)
> {
> #ifdef CONFIG_OPTIONAL_FEATURE
>
> # else
> kunit_skip(test, "CONFIG_OPTIONAL_FEATURE is not enabled");
> #endif
> }
>
> I think it's just a matter of what's least confusing to users.
Ok, I see. Is there some way to have multiple configs checked into the
tree so we can test different kernel configuration code paths? This
discussion isn't really relevant to this patch so we can take this up in
another thread if you like.
>
> >
> > Maybe kunit should check that there was an EXPECT on return from the
> > test. Daniel?
>
> Sorry, I'm not sure I understand the question.
>
> Are you saying you want kunit to flag cases like
> static void empty_test(struct kunit *) {}
> ?
Yes. I'd like kunit to enforce that all tests have at least one
EXPECT_*() in them.
