From: shejialuo <shejialuo@gmail.com>
To: git@vger.kernel.orga
Cc: git@vger.kernel.org, Patrick Steinhardt <ps@pks.im>
Subject: Re: [PATCH 2/5] u-string-list: move "test_split" into "u-string-list.c"
Date: Thu, 24 Apr 2025 20:50:14 +0800 [thread overview]
Message-ID: <aAozhkSJXkJ_nRPs@ArchLinux> (raw)
In-Reply-To: <xmqqr01j3n15.fsf@gitster.g>
On Tue, Apr 22, 2025 at 02:27:02PM -0700, Junio C Hamano wrote:
> shejialuo <shejialuo@gmail.com> writes:
>
> > We rely on "test-tool string-list" command to test the functionality of
> > the "string-list". However, as we have introduced clar test framework,
> > we'd better move the shell script into C program to improve speed and
> > readability.
> >
> > Create a new file "u-string-list.c" under "t/unit-tests", then update
> > the Makefile and "meson.build" to build the file. And let's first move
> > "test_split" into unit test and gradually convert the shell script into
> > C program.
> >
> > In order to create `string_list` easily by simply specifying strings in
> > the function call, create "t_vcreate_string_list_dup" and
> > "t_create_string_list_dup" functions to do above.
> >
> > Then port the shell script tests to C program and remove unused
> > "test-tool" code and tests.
> >
> > Signed-off-by: shejialuo <shejialuo@gmail.com>
> > ---
>
> This is the most interesting in the u-string-list patches, as it
> adds not just a moved test but adds supporting functions that are
> shared with test functions added in later steps.
>
> > diff --git a/t/unit-tests/u-string-list.c b/t/unit-tests/u-string-list.c
> > new file mode 100644
> > index 0000000000..0c148684ea
> > --- /dev/null
> > +++ b/t/unit-tests/u-string-list.c
> > @@ -0,0 +1,86 @@
> > +#include "unit-test.h"
> > +#include "string-list.h"
> > +
> > +static void t_check_string_list(struct string_list *list,
> > + struct string_list *expected_strings)
> > +{
> > + size_t expect_len = expected_strings->nr;
> > + cl_assert_equal_i(list->nr, expect_len);
> > + cl_assert(list->nr <= list->alloc);
> > + for (size_t i = 0; i < expect_len; i++)
> > + cl_assert_equal_s(list->items[i].string,
> > + expected_strings->items[i].string);
> > +}
>
> Perhaps call it "string_list_equal()" or something? "check" is a
> convenient name that can mean different kind of validation that is
> not limited to "is the actual answer identical to the expected one?"
>
Good idea.
> Wouldn't it be cleaner to read if you wrote it without an extra
> variable expect_len? The compiler would notice repeated reference
> of expected_strings->nr and optimize them away anyway, I would
> imagine.
>
Yeah, the compiler would definitely optimize this. Will update in the
next version.
> > +static void t_string_list_clear(struct string_list *list, int free_util)
> > +{
> > + string_list_clear(list, free_util);
> > + cl_assert_equal_p(list->items, NULL);
> > + cl_assert_equal_i(list->nr, 0);
> > + cl_assert_equal_i(list->alloc, 0);
> > +}
>
> Validating the result of clearing a list may be a good thing to do
> at least once in the test suite, but this is called from many places
> in other tests. Conceptually it feels kludgy to call this from
> other places where they should all just call string_list_clear(),
> like ...
>
I agree that we should not call `t_string_list_clear` in many places.
It's overkill.
> > +static void t_vcreate_string_list_dup(struct string_list *list,
> > + int free_util, va_list ap)
> > +{
> > + const char *arg;
> > +
> > + cl_assert(list->strdup_strings);
> > +
> > + t_string_list_clear(list, free_util);
>
> ... this place.
>
> > + while ((arg = va_arg(ap, const char *)))
> > + string_list_append(list, arg);
> > +}
>
> To put it differently, you could be calling t_string_list_append()
> in this loop, which would
>
> - remember list->nr
> - call string_list_append()
> - cl_assert_equal() to ensure that list->nr is one larger than
> the value we remembered upon entry to the function.
>
> which is not wrong per-se, but hopefully you'd agree that it is
> overkill. t_stirng_list_clear() is overkill in the same way.
>
You're right. I will improve this in the next version.
> > +void test_string_list__split(void)
> > +{
> > + struct string_list expected_strings = STRING_LIST_INIT_DUP;
> > +
> > + t_create_string_list_dup(&expected_strings, 0, "foo", "bar", "baz", NULL);
> > +...
> > + t_create_string_list_dup(&expected_strings, 0, "", "", NULL);
> > + t_string_list_split(":", ':', -1, &expected_strings);
> > +
> > + t_string_list_clear(&expected_strings, 0);
> > +}
>
> This is a good place to call t_string_list_clear(), just once in
> this script. All other callers are conceptually simpler to call
> string_list_clear(), as the point at their callsites is to clear
> after themselves, not about testing string_list_clear() works
> correctly.
>
> Thanks.
Thanks,
Jialuo
>
next prev parent reply other threads:[~2025-04-24 12:50 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-22 14:53 [PATCH 0/5] enhance "string_list" code and test shejialuo
2025-04-22 14:54 ` [PATCH 1/5] string-list: fix sign compare warnings shejialuo
2025-04-22 21:02 ` Junio C Hamano
2025-04-24 12:27 ` shejialuo
2025-04-22 14:54 ` [PATCH 2/5] u-string-list: move "test_split" into "u-string-list.c" shejialuo
2025-04-22 21:27 ` Junio C Hamano
2025-04-24 12:50 ` shejialuo [this message]
2025-04-23 11:52 ` Patrick Steinhardt
2025-04-24 12:53 ` shejialuo
2025-04-22 14:55 ` [PATCH 3/5] u-string-list: move "test_split_in_place" to "u-string-list.c" shejialuo
2025-04-23 11:53 ` Patrick Steinhardt
2025-04-22 14:55 ` [PATCH 4/5] u-string-list: move "filter string" test " shejialuo
2025-04-22 14:55 ` [PATCH 5/5] u-string-list: move "remove duplicates" " shejialuo
2025-04-23 11:53 ` Patrick Steinhardt
2025-04-24 12:56 ` shejialuo
2025-05-18 15:55 ` [PATCH v2 0/8] enhance "string_list" code and test shejialuo
2025-05-18 15:56 ` [PATCH v2 1/8] string-list: fix sign compare warnings for loop iterator shejialuo
2025-05-19 7:17 ` Patrick Steinhardt
2025-05-26 13:50 ` shejialuo
2025-05-18 15:57 ` [PATCH v2 2/8] string-list: remove unused "insert_at" parameter from add_entry shejialuo
2025-05-19 7:17 ` Patrick Steinhardt
2025-05-26 13:52 ` shejialuo
2025-05-19 7:51 ` Jeff King
2025-05-26 14:01 ` shejialuo
2025-05-26 14:21 ` Patrick Steinhardt
2025-05-18 15:57 ` [PATCH v2 3/8] string-list: return index directly when inserting an existing element shejialuo
2025-05-19 7:18 ` Patrick Steinhardt
2025-05-26 14:13 ` shejialuo
2025-05-19 7:58 ` Jeff King
2025-05-26 14:20 ` shejialuo
2025-05-18 15:57 ` [PATCH v2 4/8] string-list: enable sign compare warnings check shejialuo
2025-05-19 7:18 ` Patrick Steinhardt
2025-05-26 14:27 ` shejialuo
2025-05-18 15:57 ` [PATCH v2 5/8] u-string-list: move "test_split" into "u-string-list.c" shejialuo
2025-05-19 7:17 ` Patrick Steinhardt
2025-05-18 15:57 ` [PATCH v2 6/8] u-string-list: move "test_split_in_place" to "u-string-list.c" shejialuo
2025-05-18 15:58 ` [PATCH v2 7/8] u-string-list: move "filter string" test " shejialuo
2025-05-19 7:18 ` Patrick Steinhardt
2025-05-26 14:33 ` shejialuo
2025-05-18 15:58 ` [PATCH v2 8/8] u-string-list: move "remove duplicates" " shejialuo
2025-05-19 7:18 ` Patrick Steinhardt
2025-06-29 4:26 ` [PATCH v3 0/8] enhance "string_list" code and test shejialuo
2025-06-29 4:27 ` [PATCH v3 1/8] string-list: fix sign compare warnings for loop iterator shejialuo
2025-06-29 4:27 ` [PATCH v3 2/8] string-list: remove unused "insert_at" parameter from add_entry shejialuo
2025-06-29 4:27 ` [PATCH v3 3/8] string-list: return index directly when inserting an existing element shejialuo
2025-06-29 4:28 ` [PATCH v3 4/8] string-list: enable sign compare warnings check shejialuo
2025-06-29 4:28 ` [PATCH v3 5/8] u-string-list: move "test_split" into "u-string-list.c" shejialuo
2025-06-29 4:28 ` [PATCH v3 6/8] u-string-list: move "test_split_in_place" to "u-string-list.c" shejialuo
2025-06-29 4:28 ` [PATCH v3 7/8] u-string-list: move "filter string" test " shejialuo
2025-06-29 4:28 ` [PATCH v3 8/8] u-string-list: move "remove duplicates" " shejialuo
2025-07-04 5:24 ` [PATCH v3 0/8] enhance "string_list" code and test Patrick Steinhardt
2025-07-07 15:10 ` Junio C Hamano
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=aAozhkSJXkJ_nRPs@ArchLinux \
--to=shejialuo@gmail.com \
--cc=git@vger.kernel.org \
--cc=git@vger.kernel.orga \
--cc=ps@pks.im \
/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;
as well as URLs for NNTP newsgroup(s).