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 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.