From: Junio C Hamano <gitster@pobox.com>
To: Josh Steadmon <steadmon@google.com>
Cc: Ghanshyam Thakkar <shyamthakkar001@gmail.com>,
git@vger.kernel.org,
Christian Couder <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: port helper/test-hashmap.c to unit-tests/t-hashmap.c
Date: Tue, 09 Jul 2024 14:42:45 -0700 [thread overview]
Message-ID: <xmqqcynmdyy2.fsf@gitster.g> (raw)
In-Reply-To: <mlnerj7j6knamzj3ipnd7rgqd6xm5xrjep35rldhv6sikzipu5@72szgbso6cpo> (Josh Steadmon's message of "Tue, 9 Jul 2024 12:34:47 -0700")
Josh Steadmon <steadmon@google.com> writes:
>> +static void t_put(struct hashmap *map, int ignore_case)
>> +{
>> + struct test_entry *entry;
>> + const char *key_val[][2] = { { "key1", "value1" },
>> + { "key2", "value2" },
>> + { "fooBarFrotz", "value3" } };
>> +
>> + for (size_t i = 0; i < ARRAY_SIZE(key_val); i++) {
>> + entry = alloc_test_entry(ignore_case, key_val[i][0], key_val[i][1]);
>> + check(hashmap_put_entry(map, entry, ent) == NULL);
>> + }
>> +
>> + entry = alloc_test_entry(ignore_case, "foobarfrotz", "value4");
>> + entry = hashmap_put_entry(map, entry, ent);
>> + check(ignore_case ? entry != NULL : entry == NULL);
>> + free(entry);
>> +
>> + check_int(map->tablesize, ==, 64);
>> + check_int(hashmap_get_size(map), ==,
>> + ignore_case ? ARRAY_SIZE(key_val) : ARRAY_SIZE(key_val) + 1);
>> +}
>
> Ahhh, so you're using the same function for both case-sensitive and
> -insensitive tests. So I guess TEST_RUN isn't useful here after all.
> Personally I'd still rather get rid of setup(), but I don't feel super
> strongly about it.
Consulting the table with "fooBarFrotz" and checking what gets
returned (expect "value3" for !icase, or "value4" for icase) is one
of the things that are missing. In fact, the values stored are not
even checked with the above test at all.
>> +static void t_replace(struct hashmap *map, int ignore_case)
>> +{
>> + struct test_entry *entry;
>> +
>> + entry = alloc_test_entry(ignore_case, "key1", "value1");
>> + check(hashmap_put_entry(map, entry, ent) == NULL);
>> +
>> + entry = alloc_test_entry(ignore_case, ignore_case ? "Key1" : "key1",
>> + "value2");
>> + entry = hashmap_put_entry(map, entry, ent);
>> + if (check(entry != NULL))
>> + check_str(get_value(entry), "value1");
>> + free(entry);
>> +
>> + entry = alloc_test_entry(ignore_case, "fooBarFrotz", "value3");
>> + check(hashmap_put_entry(map, entry, ent) == NULL);
>> +
>> + entry = alloc_test_entry(ignore_case,
>> + ignore_case ? "foobarfrotz" : "fooBarFrotz",
>> + "value4");
Curious. If the hashmap is set up for icase use, do callers still
need to downcase the key? Shouldn't the library take care of that?
After all, test_entry_cmp() when the hashmap is being used in icase
mode does strcasecmp() anyway.
>> + entry = hashmap_put_entry(map, entry, ent);
>> + if (check(entry != NULL))
>> + check_str(get_value(entry), "value3");
Here the stored value is checked, which is good.
>> + free(entry);
>> +}
>> +
>> +static void t_get(struct hashmap *map, int ignore_case)
>> +{
>> + struct test_entry *entry;
>> + const char *key_val[][2] = { { "key1", "value1" },
>> + { "key2", "value2" },
>> + { "fooBarFrotz", "value3" },
>> + { ignore_case ? "key4" : "foobarfrotz", "value4" } };
>> + const char *query[][2] = {
>> + { ignore_case ? "Key1" : "key1", "value1" },
>> + { ignore_case ? "keY2" : "key2", "value2" },
>> + { ignore_case ? "foobarfrotz" : "fooBarFrotz", "value3" }
>> + };
>> +
>> + for (size_t i = 0; i < ARRAY_SIZE(key_val); i++) {
>> + entry = alloc_test_entry(ignore_case, key_val[i][0], key_val[i][1]);
>> + check(hashmap_put_entry(map, entry, ent) == NULL);
>> + }
>> +
>> + for (size_t i = 0; i < ARRAY_SIZE(query); i++) {
>> + entry = get_test_entry(map, ignore_case, query[i][0]);
>> + if (check(entry != NULL))
>> + check_str(get_value(entry), query[i][1]);
>> + }
>> +
>> + check(get_test_entry(map, ignore_case, "notInMap") == NULL);
>> +}
It is getting dubious if it is worth having t_put, when t_get does
so similar things and more.
Same comment applies wrt icase, and not limited to t_get() but all
the remaining test functions (elided).
Thanks.
next prev parent reply other threads:[~2024-07-09 21:42 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-28 12:41 [GSoC][PATCH] t: port helper/test-hashmap.c to unit-tests/t-hashmap.c Ghanshyam Thakkar
2024-07-08 16:15 ` [GSoC][PATCH v2] " Ghanshyam Thakkar
2024-07-09 19:34 ` Josh Steadmon
2024-07-09 21:42 ` Junio C Hamano [this message]
2024-07-10 19:41 ` Ghanshyam Thakkar
2024-07-09 23:27 ` Ghanshyam Thakkar
2024-07-10 10:19 ` Phillip Wood
2024-07-11 18:54 ` Ghanshyam Thakkar
2024-07-11 23:51 ` [GSoC][PATCH v3] " Ghanshyam Thakkar
2024-07-12 0:00 ` Ghanshyam Thakkar
2024-07-12 17:14 ` Junio C Hamano
2024-07-25 12:48 ` Christian Couder
2024-07-30 11:50 ` [PATCH v4] " A U Thor
2024-07-31 17:18 ` Christian Couder
2024-07-31 18:50 ` Junio C Hamano
2024-08-02 2:28 ` Ghanshyam Thakkar
2024-08-03 13:34 ` [GSoC][PATCH v5] " Ghanshyam Thakkar
2024-08-07 14:33 ` Christian Couder
2024-08-07 14:44 ` Ghanshyam Thakkar
2024-08-07 16:20 ` 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=xmqqcynmdyy2.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=chriscool@tuxfamily.org \
--cc=christian.couder@gmail.com \
--cc=git@vger.kernel.org \
--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 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).