From: Boqun Feng <boqun.feng@gmail.com>
To: David Gow <davidgow@google.com>
Cc: "Miguel Ojeda" <ojeda@kernel.org>,
"Brendan Higgins" <brendan.higgins@linux.dev>,
"Alex Gaynor" <alex.gaynor@gmail.com>,
"Rae Moar" <rmoar@google.com>,
linux-kselftest@vger.kernel.org, kunit-dev@googlegroups.com,
"Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Benno Lossin" <benno.lossin@proton.me>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Alice Ryhl" <aliceryhl@google.com>,
"Trevor Gross" <tmgross@umich.edu>,
"Danilo Krummrich" <dakr@kernel.org>,
rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org,
patches@lists.linux.dev
Subject: Re: [PATCH 2/7] rust: kunit: support checked `-> Result`s in KUnit `#[test]`s
Date: Mon, 5 May 2025 12:34:51 -0700 [thread overview]
Message-ID: <681912de.050a0220.383f17.18c4@mx.google.com> (raw)
In-Reply-To: <CABVgOSm8T+_kXY78sioUHEcG7rYApfWK2Gfxkrvw94Dz57G0oQ@mail.gmail.com>
On Mon, May 05, 2025 at 02:02:09PM +0800, David Gow wrote:
> On Sat, 3 May 2025 at 05:51, Miguel Ojeda <ojeda@kernel.org> wrote:
> >
> > Currently, return values of KUnit `#[test]` functions are ignored.
> >
> > Thus introduce support for `-> Result` functions by checking their
> > returned values.
> >
> > At the same time, require that test functions return `()` or `Result<T,
> > E>`, which should avoid mistakes, especially with non-`#[must_use]`
> > types. Other types can be supported in the future if needed.
> >
> > With this, a failing test like:
> >
> > #[test]
> > fn my_test() -> Result {
> > f()?;
> > Ok(())
> > }
> >
> > will output:
> >
> > [ 3.744214] KTAP version 1
> > [ 3.744287] # Subtest: my_test_suite
> > [ 3.744378] # speed: normal
> > [ 3.744399] 1..1
> > [ 3.745817] # my_test: ASSERTION FAILED at rust/kernel/lib.rs:321
> > [ 3.745817] Expected is_test_result_ok(my_test()) to be true, but is false
> > [ 3.747152] # my_test.speed: normal
> > [ 3.747199] not ok 1 my_test
> > [ 3.747345] not ok 4 my_test_suite
> >
> > Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
> > ---
>
> This is a neat idea. I think a lot of tests will still want to go with
> the () return value, but having both as an option seems like a good
> idea to me.
>
Handling the return value of a test is definitely a good thing, but I'm
not sure returning `Err` should be treated as assertion failure
though. Considering:
#[test]
fn foo() -> Result {
let b = KBox::new(...)?; // need to allocate memory for the test
use_box(b);
assert!(...);
}
if the test runs without enough memory, then KBox::new() would return a
Err(ENOMEM), and technically, it's not a test failure rather the test
has been skipped because of no enough resource.
I would suggest we handle the `Err` returns specially (mark as "SKIPPED"
maybe?).
Thoughts?
Regards,
Boqun
> Reviewed-by: David Gow <davidgow@google.com>
>
> Cheers,
> -- David
>
>
> > rust/kernel/kunit.rs | 25 +++++++++++++++++++++++++
> > rust/macros/kunit.rs | 3 ++-
> > 2 files changed, 27 insertions(+), 1 deletion(-)
> >
> > diff --git a/rust/kernel/kunit.rs b/rust/kernel/kunit.rs
> > index 2659895d4c5d..f43e3ed460c2 100644
> > --- a/rust/kernel/kunit.rs
> > +++ b/rust/kernel/kunit.rs
> > @@ -164,6 +164,31 @@ macro_rules! kunit_assert_eq {
> > }};
> > }
> >
> > +trait TestResult {
> > + fn is_test_result_ok(&self) -> bool;
> > +}
> > +
> > +impl TestResult for () {
> > + fn is_test_result_ok(&self) -> bool {
> > + true
> > + }
> > +}
> > +
> > +impl<T, E> TestResult for Result<T, E> {
> > + fn is_test_result_ok(&self) -> bool {
> > + self.is_ok()
> > + }
> > +}
> > +
> > +/// Returns whether a test result is to be considered OK.
> > +///
> > +/// This will be `assert!`ed from the generated tests.
> > +#[doc(hidden)]
> > +#[expect(private_bounds)]
> > +pub fn is_test_result_ok(t: impl TestResult) -> bool {
> > + t.is_test_result_ok()
> > +}
> > +
> > /// Represents an individual test case.
> > ///
> > /// The [`kunit_unsafe_test_suite!`] macro expects a NULL-terminated list of valid test cases.
> > diff --git a/rust/macros/kunit.rs b/rust/macros/kunit.rs
> > index eb4f2afdbe43..9681775d160a 100644
> > --- a/rust/macros/kunit.rs
> > +++ b/rust/macros/kunit.rs
> > @@ -105,8 +105,9 @@ pub(crate) fn kunit_tests(attr: TokenStream, ts: TokenStream) -> TokenStream {
> > let path = crate::helpers::file();
> > for test in &tests {
> > let kunit_wrapper_fn_name = format!("kunit_rust_wrapper_{}", test);
> > + // An extra `use` is used here to reduce the length of the message.
> > let kunit_wrapper = format!(
> > - "unsafe extern \"C\" fn {}(_test: *mut kernel::bindings::kunit) {{ {}(); }}",
> > + "unsafe extern \"C\" fn {}(_test: *mut kernel::bindings::kunit) {{ use kernel::kunit::is_test_result_ok; assert!(is_test_result_ok({}())); }}",
> > kunit_wrapper_fn_name, test
> > );
> > writeln!(kunit_macros, "{kunit_wrapper}").unwrap();
> > --
> > 2.49.0
> >
next prev parent reply other threads:[~2025-05-05 19:34 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-02 21:51 [PATCH 0/7] Rust KUnit `#[test]` support improvements Miguel Ojeda
2025-05-02 21:51 ` [PATCH 1/7] rust: kunit: support KUnit-mapped `assert!` macros in `#[test]`s Miguel Ojeda
2025-05-04 17:41 ` Tamir Duberstein
2025-05-27 0:02 ` Miguel Ojeda
2025-05-05 6:02 ` David Gow
2025-05-27 0:08 ` Miguel Ojeda
2025-05-02 21:51 ` [PATCH 2/7] rust: kunit: support checked `-> Result`s in KUnit `#[test]`s Miguel Ojeda
2025-05-04 17:33 ` Tamir Duberstein
2025-05-04 17:59 ` Miguel Ojeda
2025-05-05 6:03 ` David Gow
2025-05-05 6:02 ` David Gow
2025-05-05 19:34 ` Boqun Feng [this message]
2025-05-06 6:32 ` David Gow
2025-05-27 15:22 ` Miguel Ojeda
2025-05-02 21:51 ` [PATCH 3/7] rust: add `kunit_tests` to the prelude Miguel Ojeda
2025-05-05 6:02 ` David Gow
2025-05-02 21:51 ` [PATCH 4/7] rust: str: convert `rusttest` tests into KUnit Miguel Ojeda
2025-05-04 17:30 ` Tamir Duberstein
2025-05-04 18:31 ` Miguel Ojeda
2025-05-04 18:39 ` Tamir Duberstein
2025-05-04 19:02 ` Miguel Ojeda
2025-05-05 6:03 ` David Gow
2025-05-05 6:02 ` David Gow
2025-05-10 1:58 ` John Hubbard
2025-05-02 21:51 ` [PATCH 5/7] rust: str: take advantage of the `-> Result` support in KUnit `#[test]`'s Miguel Ojeda
2025-05-04 17:29 ` Tamir Duberstein
2025-05-04 18:15 ` Miguel Ojeda
2025-05-04 18:22 ` Tamir Duberstein
2025-05-04 21:54 ` Miguel Ojeda
2025-05-05 6:03 ` David Gow
2025-05-05 6:02 ` David Gow
2025-05-02 21:51 ` [PATCH 6/7] Documentation: rust: rename `#[test]`s to "`rusttest` host tests" Miguel Ojeda
2025-05-05 6:02 ` David Gow
2025-05-02 21:51 ` [PATCH 7/7] Documentation: rust: testing: add docs on the new KUnit `#[test]` tests Miguel Ojeda
2025-05-05 6:02 ` David Gow
2025-05-05 16:57 ` [PATCH 0/7] Rust KUnit `#[test]` support improvements Danilo Krummrich
2025-05-05 17:07 ` Miguel Ojeda
2025-05-27 0:10 ` Miguel Ojeda
2025-05-27 0:12 ` Miguel Ojeda
2025-05-28 8:03 ` Miguel Ojeda
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=681912de.050a0220.383f17.18c4@mx.google.com \
--to=boqun.feng@gmail.com \
--cc=a.hindborg@kernel.org \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=benno.lossin@proton.me \
--cc=bjorn3_gh@protonmail.com \
--cc=brendan.higgins@linux.dev \
--cc=dakr@kernel.org \
--cc=davidgow@google.com \
--cc=gary@garyguo.net \
--cc=kunit-dev@googlegroups.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=ojeda@kernel.org \
--cc=patches@lists.linux.dev \
--cc=rmoar@google.com \
--cc=rust-for-linux@vger.kernel.org \
--cc=tmgross@umich.edu \
/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