All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ivan Orlov <ivan.orlov0322@gmail.com>
To: Rae Moar <rmoar@google.com>
Cc: brendan.higgins@linux.dev, davidgow@google.com,
	linux-kselftest@vger.kernel.org, kunit-dev@googlegroups.com,
	linux-kernel@vger.kernel.org, skhan@linuxfoundation.org
Subject: Re: [PATCH] kunit: Cover 'assert.c' with tests
Date: Fri, 3 May 2024 12:10:43 +0100	[thread overview]
Message-ID: <89c0f7c2-145c-4d4c-a330-f0fff5bb4098@gmail.com> (raw)
In-Reply-To: <CA+GJov45uEfrXVWSUxvzOLYKPCnTeYeGqHvk=W4n-W_TLYyRuQ@mail.gmail.com>

On 5/2/24 00:20, Rae Moar wrote:
> On Sat, Apr 27, 2024 at 6:04 PM Ivan Orlov <ivan.orlov0322@gmail.com> wrote:
>>
>> There are multiple assertion formatting functions in the `assert.c`
>> file, which are not covered with tests yet. Implement the KUnit test
>> for these functions.
>>
>> The test consists of 11 test cases for the following functions:
>>
>> 1) 'is_literal'
>> 2) 'is_str_literal'
>> 3) 'kunit_assert_prologue', test case for multiple assert types
>> 4) 'kunit_assert_print_msg'
>> 5) 'kunit_unary_assert_format'
>> 6) 'kunit_ptr_not_err_assert_format'
>> 7) 'kunit_binary_assert_format'
>> 8) 'kunit_binary_ptr_assert_format'
>> 9) 'kunit_binary_str_assert_format'
>> 10) 'kunit_assert_hexdump'
>> 11) 'kunit_mem_assert_format'
>>
>> The test aims at maximizing the branch coverage for the assertion
>> formatting functions. As you can see, it covers some of the static
>> helper functions as well, so we have to import the test source in the
>> `assert.c` file in order to be able to call and validate them.
>>
>> Signed-off-by: Ivan Orlov <ivan.orlov0322@gmail.com>
> 
> Hello!
> 
> This is a great patch and addition of KUnit tests. Happy to see it.
> Thank you very much!
> 
> I do have a few comments below. But none of them are deal breakers.


Hi Rae,

Thank you so much for the detailed review.

> 
>> ---
>>   lib/kunit/assert.c      |   4 +
>>   lib/kunit/assert_test.c | 416 ++++++++++++++++++++++++++++++++++++++++
>>   2 files changed, 420 insertions(+)
>>   create mode 100644 lib/kunit/assert_test.c
>>
>> diff --git a/lib/kunit/assert.c b/lib/kunit/assert.c
>> index dd1d633d0fe2..ab68c6daf546 100644
>> --- a/lib/kunit/assert.c
>> +++ b/lib/kunit/assert.c
>> @@ -270,3 +270,7 @@ void kunit_mem_assert_format(const struct kunit_assert *assert,
>>          }
>>   }
>>   EXPORT_SYMBOL_GPL(kunit_mem_assert_format);
>> +
>> +#if IS_ENABLED(CONFIG_KUNIT_TEST)
>> +#include "assert_test.c"
>> +#endif
> 
> I might consider using the macro VISIBLE_IF_KUNIT macro, found in
> include/kunit/visibility.h, to make the static functions in assert.c
> visible only if KUnit is enabled. To avoid having to add the include
> here. What do you think?
> 

Wow, I haven't seen this macro before, thank you for the suggestion! 
I'll use it in the V2 of the patch.

I assume we need to use it in combination with EXPORT_SYMBOL_IF_KUNIT, 
otherwise GCC will complain on use of functions without definitions, right?

Also, should the assertion test be in a different file in such a case, 
or we could merge it with one of the existing test files, for instance 
`kunit_test.c`? Having these static functions exported would allow us to 
do that.

>> diff --git a/lib/kunit/assert_test.c b/lib/kunit/assert_test.c
>> new file mode 100644
>> index 000000000000..d54841740761
>> --- /dev/null
>> +++ b/lib/kunit/assert_test.c
>> @@ -0,0 +1,416 @@
>> +// SPDX-License-Identifier: GPL-2.0-or-later
>> +/*
>> + * KUnit test for the assertion formatting functions.
>> + * Author: Ivan Orlov <ivan.orlov0322@gmail.com>
>> + */
>> +#include <kunit/test.h>
>> +
>> +#define TEST_PTR_EXPECTED_BUF_SIZE 128
>> +
>> +static void kunit_test_is_literal(struct kunit *test)
>> +{
>> +       KUNIT_EXPECT_TRUE(test, is_literal("5", 5));
>> +       KUNIT_EXPECT_TRUE(test, is_literal("0", 0));
>> +       KUNIT_EXPECT_TRUE(test, is_literal("1234567890", 1234567890));
>> +       KUNIT_EXPECT_TRUE(test, is_literal("-1234567890", -1234567890));
>> +       KUNIT_EXPECT_FALSE(test, is_literal("05", 5));
>> +       KUNIT_EXPECT_FALSE(test, is_literal("", 0));
>> +       KUNIT_EXPECT_FALSE(test, is_literal("-0", 0));
>> +       KUNIT_EXPECT_FALSE(test, is_literal("12#45", 1245));
>> +}
>> +
>> +static void kunit_test_is_str_literal(struct kunit *test)
>> +{
>> +       KUNIT_EXPECT_TRUE(test, is_str_literal("\"Hello, World!\"", "Hello, World!"));
>> +       KUNIT_EXPECT_TRUE(test, is_str_literal("\"\"", ""));
>> +       KUNIT_EXPECT_TRUE(test, is_str_literal("\"\"\"", "\""));
>> +       KUNIT_EXPECT_FALSE(test, is_str_literal("", ""));
>> +       KUNIT_EXPECT_FALSE(test, is_str_literal("\"", "\""));
>> +       KUNIT_EXPECT_FALSE(test, is_str_literal("\"Abacaba", "Abacaba"));
>> +       KUNIT_EXPECT_FALSE(test, is_str_literal("Abacaba\"", "Abacaba"));
>> +       KUNIT_EXPECT_FALSE(test, is_str_literal("\"Abacaba\"", "\"Abacaba\""));
>> +}
>> +
>> +KUNIT_DEFINE_ACTION_WRAPPER(kfree_wrapper, kfree, const void *);
>> +
>> +/* this function is used to get a "char *" string from the string stream and defer its cleanup  */
>> +static char *get_str_from_stream(struct kunit *test, struct string_stream *stream)
>> +{
>> +       char *str = string_stream_get_string(stream);
>> +
>> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, str);
>> +       kunit_add_action(test, kfree_wrapper, (void *)str);
>> +
>> +       return str;
>> +}
>> +
>> +static void kunit_test_assert_prologue(struct kunit *test)
>> +{
>> +       struct string_stream *stream;
>> +       const struct kunit_loc location = {
>> +               .file = "testfile.c",
>> +               .line = 1337,
>> +       };
>> +
>> +       stream = kunit_alloc_string_stream(test, GFP_KERNEL);
>> +       KUNIT_ASSERT_NOT_ERR_OR_NULL(test, stream);
>> +
>> +       /* Test an expectation fail prologue */
>> +       kunit_assert_prologue(&location, KUNIT_EXPECTATION, stream);
>> +       KUNIT_EXPECT_STREQ(test, get_str_from_stream(test, stream),
>> +                          "EXPECTATION FAILED at testfile.c:1337\n");
>> +
>> +       /* Test an assertion fail prologue */
>> +       string_stream_clear(stream);
>> +       kunit_assert_prologue(&location, KUNIT_ASSERTION, stream);
>> +       KUNIT_EXPECT_STREQ(test, get_str_from_stream(test, stream),
>> +                          "ASSERTION FAILED at testfile.c:1337\n");
> 
> My one main concern with some of these tests is that they test for
> exact matches to string error messages. I worry that these error
> messages are likely to change over time, especially the indentation
> and spacing of the messages. This applies more to some of the tests
> below that check for the indentation.
> 
> I think it is most important that we test for the message containing
> the correct information. Is there a way to instead check if the stream
> contains each of a list of important information. So for example in
> the test above, I think it is important to check the stream contains
> the following strings: "ASSERTION" (maybe even not check for case),
> "testfile.c",  "1337", and "\n" at the end of the stream.
> 
> This applies to the tests below as well. Although, I do see how it may
> be difficult to change this. If there is a way to at least remove the
> checks for indentation and any filler words that would be great.
> 

Yes, I fully agree, checking for the important information would be a 
better way of testing these functions.

My initial intention was to check for the format and indentation as well 
to be sure that some change won't break any of existing parsers (I 
assume there are some parsers for KUnit test output :) ), but in fact 
this approach just bloats the test and makes it less readable. I will 
fix it in the V2, thanks!
-- 
Kind regards,
Ivan Orlov


  reply	other threads:[~2024-05-03 11:10 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-27 22:04 [PATCH] kunit: Cover 'assert.c' with tests Ivan Orlov
2024-04-29 21:26 ` Rae Moar
2024-04-30  9:19   ` Ivan Orlov
2024-05-01 23:20 ` Rae Moar
2024-05-03 11:10   ` Ivan Orlov [this message]
2024-05-03 12:18     ` Ivan Orlov
2024-05-04 16:45     ` Ivan Orlov

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=89c0f7c2-145c-4d4c-a330-f0fff5bb4098@gmail.com \
    --to=ivan.orlov0322@gmail.com \
    --cc=brendan.higgins@linux.dev \
    --cc=davidgow@google.com \
    --cc=kunit-dev@googlegroups.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=rmoar@google.com \
    --cc=skhan@linuxfoundation.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.