From: David Gow <davidgow@google.com>
To: Eric Chan <ericchancf@google.com>
Cc: brendan.higgins@linux.dev, rmoar@google.com,
linux-kselftest@vger.kernel.org, kunit-dev@googlegroups.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/3] kunit: Rename KUNIT_ASSERT_FAILURE to KUNIT_ASSERT for readability
Date: Thu, 11 Jul 2024 11:49:33 +0800 [thread overview]
Message-ID: <CABVgOSkJOyLDZmPk5vj+o7aRbEZFDJvynWRacNJZ_M_gn9x1XQ@mail.gmail.com> (raw)
In-Reply-To: <20240710170643.1401358-1-ericchancf@google.com>
[-- Attachment #1: Type: text/plain, Size: 3556 bytes --]
On Thu, 11 Jul 2024 at 01:06, Eric Chan <ericchancf@google.com> wrote:
>
> Both KUNIT_FAIL and KUNIT_ASSERT_FAILURE defined to KUNIT_FAIL_ASSERTION
> with different tpye of kunit_assert_type. The current naming of
> KUNIT_ASSERT_FAILURE and KUNIT_FAIL_ASSERTION is confusing due to their
> similarities. To improve readability and symmetry, renames
> KUNIT_ASSERT_FAILURE to KUNIT_ASSERT. Makes the naming consistent,
> with KUNIT_FAIL and KUNIT_ASSERT being symmetrical.
> Additionally, an explanation for KUNIT_ASSERT has been added to clarify
> its usage.
>
> Signed-off-by: Eric Chan <ericchancf@google.com>
> ---
I personally am not a fan of KUNIT_ASSERT() as a name here: to me it
implies that we're checking a boolean (like KUNIT_ASSERT_TRUE()).
Does making this 'KUNIT_FAIL_AND_EXIT()' / 'KUNIT_FAIL_AND_ABORT()' or
similar seem clearer to you?
(Or possibly we could make this KUNIT_FAIL(), and make the existing
KUNIT_FAIL() become KUNIT_MARK_FAILED(), though I think it's not worth
the churn personally.)
-- David
> drivers/input/tests/input_test.c | 2 +-
> include/kunit/assert.h | 2 +-
> include/kunit/test.h | 13 ++++++++++++-
> 3 files changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/input/tests/input_test.c b/drivers/input/tests/input_test.c
> index 2fa5b725ae0a..cbab24a265fa 100644
> --- a/drivers/input/tests/input_test.c
> +++ b/drivers/input/tests/input_test.c
> @@ -31,7 +31,7 @@ static int input_test_init(struct kunit *test)
> ret = input_register_device(input_dev);
> if (ret) {
> input_free_device(input_dev);
> - KUNIT_ASSERT_FAILURE(test, "Register device failed: %d", ret);
> + KUNIT_ASSERT(test, "Register device failed: %d", ret);
> }
>
> test->priv = input_dev;
> diff --git a/include/kunit/assert.h b/include/kunit/assert.h
> index 24c2b9fa61e8..02c6f7bb1d26 100644
> --- a/include/kunit/assert.h
> +++ b/include/kunit/assert.h
> @@ -60,7 +60,7 @@ void kunit_assert_prologue(const struct kunit_loc *loc,
> * struct kunit_fail_assert - Represents a plain fail expectation/assertion.
> * @assert: The parent of this type.
> *
> - * Represents a simple KUNIT_FAIL/KUNIT_ASSERT_FAILURE that always fails.
> + * Represents a simple KUNIT_FAIL/KUNIT_ASSERT that always fails.
> */
> struct kunit_fail_assert {
> struct kunit_assert assert;
> diff --git a/include/kunit/test.h b/include/kunit/test.h
> index 87a232421089..d1b085fd5dc3 100644
> --- a/include/kunit/test.h
> +++ b/include/kunit/test.h
> @@ -1193,7 +1193,18 @@ do { \
> fmt, \
> ##__VA_ARGS__)
>
> -#define KUNIT_ASSERT_FAILURE(test, fmt, ...) \
> +/**
> + * KUNIT_ASSERT() - Always causes a test to assert when evaluated.
> + * @test: The test context object.
> + * @fmt: an informational message to be printed when the assertion is made.
> + * @...: string format arguments.
> + *
> + * The opposite of KUNIT_SUCCEED(), it is an assertion that always fails. In
> + * other words, it always results in a failed assertion, and consequently
> + * always causes the test case to assert when evaluated. See KUNIT_ASSERT_TRUE()
> + * for more information.
> + */
> +#define KUNIT_ASSERT(test, fmt, ...) \
> KUNIT_FAIL_ASSERTION(test, KUNIT_ASSERTION, fmt, ##__VA_ARGS__)
>
> /**
> --
> 2.45.2.803.g4e1b14247a-goog
>
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4014 bytes --]
next prev parent reply other threads:[~2024-07-11 3:49 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-10 17:04 [PATCH 0/3] kunit: Improve the readability and functionality of macro Eric Chan
2024-07-10 17:06 ` [PATCH 1/3] kunit: Fix the comment of KUNIT_ASSERT_STRNEQ as assertion Eric Chan
2024-07-11 3:48 ` David Gow
2024-07-10 17:06 ` [PATCH 2/3] kunit: Rename KUNIT_ASSERT_FAILURE to KUNIT_ASSERT for readability Eric Chan
2024-07-11 3:49 ` David Gow [this message]
2024-07-11 19:48 ` Eric Chan
2024-07-10 17:06 ` [PATCH 3/3] kunit: Introduce KUNIT_ASSERT_MEMEQ and KUNIT_ASSERT_MEMNEQ macros Eric Chan
2024-07-11 3:49 ` David Gow
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=CABVgOSkJOyLDZmPk5vj+o7aRbEZFDJvynWRacNJZ_M_gn9x1XQ@mail.gmail.com \
--to=davidgow@google.com \
--cc=brendan.higgins@linux.dev \
--cc=ericchancf@google.com \
--cc=kunit-dev@googlegroups.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=rmoar@google.com \
/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
all inboxes | Powered by JetHome®