From: Junio C Hamano <gitster@pobox.com>
To: Ghanshyam Thakkar <shyamthakkar001@gmail.com>
Cc: git@vger.kernel.org, Jonathan Nieder <jrnieder@gmail.com>,
Josh Steadmon <steadmon@google.com>,
christian.couder@gmail.com,
Phillip Wood <phillip.wood123@gmail.com>,
Christian Couder <chriscool@tuxfamily.org>,
Kaartic Sivaraam <kaartic.sivaraam@gmail.com>
Subject: Re: [GSoC][PATCH v2] t: migrate helper/test-oidmap.c to unit-tests/t-oidmap.c
Date: Mon, 01 Jul 2024 14:14:35 -0700 [thread overview]
Message-ID: <xmqq4j98vmpw.fsf@gitster.g> (raw)
In-Reply-To: <20240628122030.41554-1-shyamthakkar001@gmail.com> (Ghanshyam Thakkar's message of "Fri, 28 Jun 2024 17:50:21 +0530")
Ghanshyam Thakkar <shyamthakkar001@gmail.com> writes:
> helper/test-oidmap.c along with t0016-oidmap.sh test the oidmap.h
> library which is built on top of hashmap.h.
>
> Migrate them to the unit testing framework for better performance,
> concise code and better debugging. Along with the migration also plug
> memory leaks and make the test logic independent for all the tests.
> The migration removes 'put' tests from t0016, because it is used as
> setup to all the other tests, so testing it separately does not yield
> any benefit.
>
> Helped-by: Phillip Wood <phillip.wood123@gmail.com>
> Mentored-by: Christian Couder <chriscool@tuxfamily.org>
> Mentored-by: Kaartic Sivaraam <kaartic.sivaraam@gmail.com>
> Signed-off-by: Ghanshyam Thakkar <shyamthakkar001@gmail.com>
> ---
> This version addresses Phillip's review about detecting duplicates in
> oidmap when iterating over it ...
Hmph. You seem to overwrite key_val[i][1] ...
> +/*
> + * Elements we will put in oidmap structs are made of a key: the entry.oid
> + * field, which is of type struct object_id, and a value: the name field (could
> + * be a refname for example).
> + */
> +struct test_entry {
> + struct oidmap_entry entry;
> + char name[FLEX_ARRAY];
> +};
> +
> +static const char *key_val[][2] = { { "11", "one" },
> + { "22", "two" },
> + { "33", "three" } };
... in this test, rendering the key_val[] array unusuable for
further tests. Is that intended and desirable?
As long as t_iterate() stays to be the last test, that would be OK,
but once somebody wants to add a new test after it, i.e.
TEST(setup(t_iterate), "iterate works");
+ TEST(setup(t_frotz), "frotz works");
return test_done();
the setup() for that new test depends on the key_val[] array, whose
value fields key_val[i][1] have been modified.
The TEST(setup(t_foo)) pattern is done so nicely to make sure that
everybody is independent from everybody else, preparing the oidmap
used for each specific test from scratch. It is a bit disappointing
that we are now invalidating this nice property.
> +static int key_val_contains(struct test_entry *entry)
> +{
> + for (size_t i = 0; i < ARRAY_SIZE(key_val); i++) {
> + struct object_id oid;
> +
> + if (get_oid_arbitrary_hex(key_val[i][0], &oid))
> + return -1;
> +
> + if (oideq(&entry->entry.oid, &oid)) {
> + if (!strcmp(key_val[i][1], "USED"))
> + return 2;
> + key_val[i][1] = "USED";
> + return 0;
> + }
> + }
> + return 1;
> +}
Otherwise, the other tests looked reasonable. Looking really nice.
As I expect things to be slow this week, being a big vacation week
in the US, we may not see much review activities this week. I'll
queue this version in the meantime, not merging it down to 'next',
in case people start comment on it next week.
Thanks.
> +int cmd_main(int argc UNUSED, const char **argv UNUSED)
> +{
> + TEST(setup(t_replace), "replace works");
> + TEST(setup(t_get), "get works");
> + TEST(setup(t_remove), "remove works");
> + TEST(setup(t_iterate), "iterate works");
> + return test_done();
> +}
next prev parent reply other threads:[~2024-07-01 21:14 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-19 17:50 [GSoC][PATCH] t: migrate helper/test-oidmap.c to unit-tests/t-oidmap.c Ghanshyam Thakkar
2024-06-20 9:45 ` Jonathan Nieder
2024-06-25 1:35 ` Ghanshyam Thakkar
2024-06-25 10:14 ` Phillip Wood
2024-06-25 19:16 ` Ghanshyam Thakkar
2024-06-26 8:59 ` phillip.wood123
2024-06-28 12:20 ` [GSoC][PATCH v2] " Ghanshyam Thakkar
2024-07-01 20:32 ` Josh Steadmon
2024-07-01 21:19 ` Junio C Hamano
2024-07-01 21:14 ` Junio C Hamano [this message]
2024-07-01 22:20 ` Junio C Hamano
2024-07-02 3:48 ` Ghanshyam Thakkar
2024-07-02 15:17 ` Phillip Wood
2024-07-02 15:24 ` Phillip Wood
2024-07-02 16:25 ` Ghanshyam Thakkar
2024-07-02 18:55 ` 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=xmqq4j98vmpw.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=chriscool@tuxfamily.org \
--cc=christian.couder@gmail.com \
--cc=git@vger.kernel.org \
--cc=jrnieder@gmail.com \
--cc=kaartic.sivaraam@gmail.com \
--cc=phillip.wood123@gmail.com \
--cc=shyamthakkar001@gmail.com \
--cc=steadmon@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 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.