On Thu, Jan 20, 2022 at 4:49 PM Michał Winiarski
<michal.winiarski@xxxxxxxxx> wrote:
> > Tangent:
> > It might have been easier to do that if the kunit assertions returned pass/fail.
> > E.g. instead of having to do
> >
> > if (!<long-condition>) {
> > KUNIT_FAIL("<long-condition> not met");
> > return;
> > }
> >
> > if we could do
> >
> > if(!KUNIT_EXPECT_TRUE(long-condition))
> > return;
> >
> > or if there was a new macro type
> >
> > KUNIT_EXPECT_RET_TRUE(long-condition); // like ASSERT, but just return
> > from this func on failure
>
> This would simplify a bunch of other tests as well.
> On the other hand - EXPECT_TRUE returning a value is not something I
> would expect :)
Yeah.
It felt painful to type that out :)
But I felt the same need when looking at converting some other selftests over.
It definitely feels like there's room to make these sorts of helper
functions better.
KTF solved these by allowing asserts to `goto` or `break`, e.g.
https://github.com/oracle/ktf/blob/63c19dead80de9cd654b08120d28a04f24174f4b/kernel/ktf.h#L560
I had floated the idea of KUnit having a
KUNIT_ASSERT_GOTO/KUNIT_ASSERT_RET (return)
macro, but these would add yet another dimension to the macros (EXPECT
vs ASSERT, _MSG vs no _MSG).
But I have some patches out that delete hundreds of lines from the
assert macros along with some others I haven't sent out publicly yet.
Maybe such a thing would be more palatable after those land?
But for now, I think they can either just print enough debug info so
that the failures are obvious (like this does), or they can use
kunit_err() to print out additional info (like you do in other patches
in this series).
>
> Thanks!
> -Michał
