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:
- 'is_literal'
- 'is_str_literal'
- 'kunit_assert_prologue', test case for multiple assert types
- 'kunit_assert_print_msg'
- 'kunit_unary_assert_format'
- 'kunit_ptr_not_err_assert_format'
- 'kunit_binary_assert_format'
- 'kunit_binary_ptr_assert_format'
- 'kunit_binary_str_assert_format'
- 'kunit_assert_hexdump'
- '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!