Message ID | 20221111182906.1377191-2-dlatypov@google.com (mailing list archive) |
---|---|
State | Accepted |
Commit | ec0a42a17e463ee5b1ebd2d60337e8ae8e5ace2b |
Delegated to: | Brendan Higgins |
Headers | show |
Series | [v3,1/3] Documentation: KUnit: make usage.rst a superset of tips.rst, remove duplication | expand |
On Sat, Nov 12, 2022 at 2:29 AM Daniel Latypov <dlatypov@google.com> wrote: > > The existing wording implies that kunit_kmalloc_array() is "the method > under test". We're actually testing the sort() function in that example. > This is because the example was changed in commit 953574390634 > ("Documentation: KUnit: Rework writing page to focus on writing tests"), > but the wording was not. > > Also add a `note` telling people they can use the KUNIT_ASSERT_EQ() > macros from any function. Some users might be coming from a framework > like gUnit where that'll compile but silently do the wrong thing. > > Signed-off-by: Daniel Latypov <dlatypov@google.com> > Reviewed-by: Sadiya Kazi <sadiyakazi@google.com> > --- Looking good! Reviewed-by: David Gow <davidgow@google.com> Cheers, -- David > Documentation/dev-tools/kunit/usage.rst | 13 ++++++++----- > 1 file changed, 8 insertions(+), 5 deletions(-) > > diff --git a/Documentation/dev-tools/kunit/usage.rst b/Documentation/dev-tools/kunit/usage.rst > index b0a6c3bc0eeb..22416ebb94ab 100644 > --- a/Documentation/dev-tools/kunit/usage.rst > +++ b/Documentation/dev-tools/kunit/usage.rst > @@ -112,11 +112,14 @@ terminates the test case if the condition is not satisfied. For example: > KUNIT_EXPECT_LE(test, a[i], a[i + 1]); > } > > -In this example, the method under test should return pointer to a value. If the > -pointer returns null or an errno, we want to stop the test since the following > -expectation could crash the test case. `ASSERT_NOT_ERR_OR_NULL(...)` allows us > -to bail out of the test case if the appropriate conditions are not satisfied to > -complete the test. > +In this example, we need to be able to allocate an array to test the ``sort()`` > +function. So we use ``KUNIT_ASSERT_NOT_ERR_OR_NULL()`` to abort the test if > +there's an allocation error. > + > +.. note:: > + In other test frameworks, ``ASSERT`` macros are often implemented by calling > + ``return`` so they only work from the test function. In KUnit, we stop the > + current kthread on failure, so you can call them from anywhere. > > Customizing error messages > -------------------------- > -- > 2.38.1.431.g37b22c650d-goog >
diff --git a/Documentation/dev-tools/kunit/usage.rst b/Documentation/dev-tools/kunit/usage.rst index b0a6c3bc0eeb..22416ebb94ab 100644 --- a/Documentation/dev-tools/kunit/usage.rst +++ b/Documentation/dev-tools/kunit/usage.rst @@ -112,11 +112,14 @@ terminates the test case if the condition is not satisfied. For example: KUNIT_EXPECT_LE(test, a[i], a[i + 1]); } -In this example, the method under test should return pointer to a value. If the -pointer returns null or an errno, we want to stop the test since the following -expectation could crash the test case. `ASSERT_NOT_ERR_OR_NULL(...)` allows us -to bail out of the test case if the appropriate conditions are not satisfied to -complete the test. +In this example, we need to be able to allocate an array to test the ``sort()`` +function. So we use ``KUNIT_ASSERT_NOT_ERR_OR_NULL()`` to abort the test if +there's an allocation error. + +.. note:: + In other test frameworks, ``ASSERT`` macros are often implemented by calling + ``return`` so they only work from the test function. In KUnit, we stop the + current kthread on failure, so you can call them from anywhere. Customizing error messages --------------------------