{"thread":{"id":"62755","subject":"[PATCH 1/2] t/unit-tests: match functions signature with trailing code","startedAt":"2025-01-07T09:19:43Z","lastAt":"2025-01-09T16:14:47Z","messageCount":18,"participants":["Seyi Kuforiji","Junio C Hamano","Patrick Steinhardt","Seyi Chamber"],"isPatch":true,"patchVersion":1,"patchTotal":2},"messages":[{"id":"510059","messageId":"20250107091932.126673-1-kuforiji98@gmail.com","threadId":"62755","inReplyTo":null,"subject":"[PATCH 0/2] t/unit-tests: convert hash tests to use clar","fromName":"Seyi Kuforiji","fromEmail":"kuforiji98@gmail.com","sentAt":"2025-01-07T09:19:30Z","receivedAt":"2025-01-07T09:19:43Z","isPatch":true,"sender":{"key":"kuforiji98@gmail.com","avatar":"https://avatars.githubusercontent.com/u/94905626?v=4"},"body":"Hello,\n\nThis small patch series transitions the existing unit test file t-hash.c\nto the Clar testing framework. This change is part of our ongoing effort\nto standardize our testing approach and enhance maintainability.\n\nThanks\nSeyi\n\nMentored-by: Patrick Steinhardt ps@pks.im\nSigned-off-by: Seyi Kuforiji kuforiji98@gmail.com\n\nSeyi Kuforiji (2):\n  t/unit-tests: match functions signature with trailing code\n  t/unit-tests: convert hash to use clar test framework\n\n Makefile                            |  2 +-\n t/meson.build                       |  2 +-\n t/unit-tests/generate-clar-decls.sh |  2 +-\n t/unit-tests/t-hash.c               | 84 ----------------------------\n t/unit-tests/u-hash.c               | 85 +++++++++++++++++++++++++++++\n 5 files changed, 88 insertions(+), 87 deletions(-)\n delete mode 100644 t/unit-tests/t-hash.c\n create mode 100644 t/unit-tests/u-hash.c\n\n-- \n2.34.1\n\n"},{"id":"510057","messageId":"20250107091932.126673-2-kuforiji98@gmail.com","threadId":"62755","inReplyTo":"20250107091932.126673-1-kuforiji98@gmail.com","subject":"[PATCH 1/2] t/unit-tests: match functions signature with trailing code","fromName":"Seyi Kuforiji","fromEmail":"kuforiji98@gmail.com","sentAt":"2025-01-07T09:19:31Z","receivedAt":"2025-01-07T09:19:46Z","isPatch":true,"sender":{"key":"kuforiji98@gmail.com","avatar":"https://avatars.githubusercontent.com/u/94905626?v=4"},"body":"The `generate-clar-decls.sh` script extracts signatures of test\nfunctions from our unit tests, which will later get used by the clar to\nautomatically wire up tests. The sed command only matches lines that\nended immediately after `void)`, causing it to miss declarations with\nadditional content such as comments or annotations.\n\nRelax the regular expression by making it match lines with trailing data\nafter the function signature. This ensures that all valid function\ndeclarations are captured and formatted as `extern` declarations\nregardless of their formatting style, improving the robustness of the\nscript when parsing `$suite` files.\n\nThis will be used in subsequent commits to match and capture the\nfunction signature correctly, regardless of any trailing content.\n\nMentored-by: Patrick Steinhardt <ps@pks.im>\nSigned-off-by: Seyi Kuforiji <kuforiji98@gmail.com>\n---\n t/unit-tests/generate-clar-decls.sh | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/t/unit-tests/generate-clar-decls.sh b/t/unit-tests/generate-clar-decls.sh\nindex 3b315c64b3..02e45cf0ba 100755\n--- a/t/unit-tests/generate-clar-decls.sh\n+++ b/t/unit-tests/generate-clar-decls.sh\n@@ -14,6 +14,6 @@ do\n \tsuite_name=$(basename \"$suite\")\n \tsuite_name=${suite_name%.c}\n \tsuite_name=${suite_name#u-}\n-\tsed -ne \"s/^\\(void test_${suite_name}__[a-zA-Z_0-9][a-zA-Z_0-9]*(void)\\)$/extern \\1;/p\" \"$suite\" ||\n+\tsed -ne \"s/^\\(void test_${suite_name}__[a-zA-Z_0-9][a-zA-Z_0-9]*(void)\\).*/extern \\1;/p\" \"$suite\" ||\n \texit 1\n done >\"$OUTPUT\"\n--\n2.34.1\n\n"},{"id":"510058","messageId":"20250107091932.126673-3-kuforiji98@gmail.com","threadId":"62755","inReplyTo":"20250107091932.126673-1-kuforiji98@gmail.com","subject":"[PATCH 2/2] t/unit-tests: convert hash to use clar test framework","fromName":"Seyi Kuforiji","fromEmail":"kuforiji98@gmail.com","sentAt":"2025-01-07T09:19:32Z","receivedAt":"2025-01-07T09:19:51Z","isPatch":true,"sender":{"key":"kuforiji98@gmail.com","avatar":"https://avatars.githubusercontent.com/u/94905626?v=4"},"body":"Adapt the hash test functions to clar framework by using clar\nassertions where necessary. Following the consensus to convert\nthe unit-tests scripts found in the t/unit-tests folder to clar driven by\nPatrick Steinhardt. Test functions are structured as a standalone to\ntest individual hash string and literal case.\n\nMentored-by: Patrick Steinhardt <ps@pks.im>\nSigned-off-by: Seyi Kuforiji <kuforiji98@gmail.com>\n---\n Makefile              |  2 +-\n t/meson.build         |  2 +-\n t/unit-tests/t-hash.c | 84 ------------------------------------------\n t/unit-tests/u-hash.c | 85 +++++++++++++++++++++++++++++++++++++++++++\n 4 files changed, 87 insertions(+), 86 deletions(-)\n delete mode 100644 t/unit-tests/t-hash.c\n create mode 100644 t/unit-tests/u-hash.c\n\ndiff --git a/Makefile b/Makefile\nindex 97e8385b66..d3011e30f7 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -1338,6 +1338,7 @@ THIRD_PARTY_SOURCES += $(UNIT_TEST_DIR)/clar/%\n THIRD_PARTY_SOURCES += $(UNIT_TEST_DIR)/clar/clar/%\n \n CLAR_TEST_SUITES += u-ctype\n+CLAR_TEST_SUITES += u-hash\n CLAR_TEST_SUITES += u-strvec\n CLAR_TEST_PROG = $(UNIT_TEST_BIN)/unit-tests$(X)\n CLAR_TEST_OBJS = $(patsubst %,$(UNIT_TEST_DIR)/%.o,$(CLAR_TEST_SUITES))\n@@ -1345,7 +1346,6 @@ CLAR_TEST_OBJS += $(UNIT_TEST_DIR)/clar/clar.o\n CLAR_TEST_OBJS += $(UNIT_TEST_DIR)/unit-test.o\n \n UNIT_TEST_PROGRAMS += t-example-decorate\n-UNIT_TEST_PROGRAMS += t-hash\n UNIT_TEST_PROGRAMS += t-hashmap\n UNIT_TEST_PROGRAMS += t-mem-pool\n UNIT_TEST_PROGRAMS += t-oid-array\ndiff --git a/t/meson.build b/t/meson.build\nindex 602ebfe6a2..d722bc7dff 100644\n--- a/t/meson.build\n+++ b/t/meson.build\n@@ -1,6 +1,7 @@\n clar_test_suites = [\n   'unit-tests/u-ctype.c',\n   'unit-tests/u-strvec.c',\n+  'unit-tests/u-hash.c',\n ]\n \n clar_sources = [\n@@ -41,7 +42,6 @@ test('unit-tests', clar_unit_tests)\n \n unit_test_programs = [\n   'unit-tests/t-example-decorate.c',\n-  'unit-tests/t-hash.c',\n   'unit-tests/t-hashmap.c',\n   'unit-tests/t-mem-pool.c',\n   'unit-tests/t-oid-array.c',\ndiff --git a/t/unit-tests/t-hash.c b/t/unit-tests/t-hash.c\ndeleted file mode 100644\nindex e62647019b..0000000000\n--- a/t/unit-tests/t-hash.c\n+++ /dev/null\n@@ -1,84 +0,0 @@\n-#include \"test-lib.h\"\n-#include \"hex.h\"\n-#include \"strbuf.h\"\n-\n-static void check_hash_data(const void *data, size_t data_length,\n-\t\t\t    const char *expected_hashes[])\n-{\n-\tif (!check(data != NULL)) {\n-\t\ttest_msg(\"BUG: NULL data pointer provided\");\n-\t\treturn;\n-\t}\n-\n-\tfor (size_t i = 1; i < ARRAY_SIZE(hash_algos); i++) {\n-\t\tgit_hash_ctx ctx;\n-\t\tunsigned char hash[GIT_MAX_HEXSZ];\n-\t\tconst struct git_hash_algo *algop = &hash_algos[i];\n-\n-\t\talgop->init_fn(&ctx);\n-\t\talgop->update_fn(&ctx, data, data_length);\n-\t\talgop->final_fn(hash, &ctx);\n-\n-\t\tif (!check_str(hash_to_hex_algop(hash, algop), expected_hashes[i - 1]))\n-\t\t\ttest_msg(\"result does not match with the expected for %s\\n\", hash_algos[i].name);\n-\t}\n-}\n-\n-/* Works with a NUL terminated string. Doesn't work if it should contain a NUL character. */\n-#define TEST_HASH_STR(data, expected_sha1, expected_sha256) do { \\\n-\t\tconst char *expected_hashes[] = { expected_sha1, expected_sha256 }; \\\n-\t\tTEST(check_hash_data(data, strlen(data), expected_hashes), \\\n-\t\t     \"SHA1 and SHA256 (%s) works\", #data); \\\n-\t} while (0)\n-\n-/* Only works with a literal string, useful when it contains a NUL character. */\n-#define TEST_HASH_LITERAL(literal, expected_sha1, expected_sha256) do { \\\n-\t\tconst char *expected_hashes[] = { expected_sha1, expected_sha256 }; \\\n-\t\tTEST(check_hash_data(literal, (sizeof(literal) - 1), expected_hashes), \\\n-\t\t     \"SHA1 and SHA256 (%s) works\", #literal); \\\n-\t} while (0)\n-\n-int cmd_main(int argc UNUSED, const char **argv UNUSED)\n-{\n-\tstruct strbuf aaaaaaaaaa_100000 = STRBUF_INIT;\n-\tstruct strbuf alphabet_100000 = STRBUF_INIT;\n-\n-\tstrbuf_addstrings(&aaaaaaaaaa_100000, \"aaaaaaaaaa\", 100000);\n-\tstrbuf_addstrings(&alphabet_100000, \"abcdefghijklmnopqrstuvwxyz\", 100000);\n-\n-\tTEST_HASH_STR(\"\",\n-\t\t\"da39a3ee5e6b4b0d3255bfef95601890afd80709\",\n-\t\t\"e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855\");\n-\tTEST_HASH_STR(\"a\",\n-\t\t\"86f7e437faa5a7fce15d1ddcb9eaeaea377667b8\",\n-\t\t\"ca978112ca1bbdcafac231b39a23dc4da786eff8147c4e72b9807785afee48bb\");\n-\tTEST_HASH_STR(\"abc\",\n-\t\t\"a9993e364706816aba3e25717850c26c9cd0d89d\",\n-\t\t\"ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad\");\n-\tTEST_HASH_STR(\"message digest\",\n-\t\t\"c12252ceda8be8994d5fa0290a47231c1d16aae3\",\n-\t\t\"f7846f55cf23e14eebeab5b4e1550cad5b509e3348fbc4efa3a1413d393cb650\");\n-\tTEST_HASH_STR(\"abcdefghijklmnopqrstuvwxyz\",\n-\t\t\"32d10c7b8cf96570ca04ce37f2a19d84240d3a89\",\n-\t\t\"71c480df93d6ae2f1efad1447c66c9525e316218cf51fc8d9ed832f2daf18b73\");\n-\tTEST_HASH_STR(aaaaaaaaaa_100000.buf,\n-\t\t\"34aa973cd4c4daa4f61eeb2bdbad27316534016f\",\n-\t\t\"cdc76e5c9914fb9281a1c7e284d73e67f1809a48a497200e046d39ccc7112cd0\");\n-\tTEST_HASH_STR(alphabet_100000.buf,\n-\t\t\"e7da7c55b3484fdf52aebec9cbe7b85a98f02fd4\",\n-\t\t\"e406ba321ca712ad35a698bf0af8d61fc4dc40eca6bdcea4697962724ccbde35\");\n-\tTEST_HASH_LITERAL(\"blob 0\\0\",\n-\t\t\"e69de29bb2d1d6434b8b29ae775ad8c2e48c5391\",\n-\t\t\"473a0f4c3be8a93681a267e3b1e9a7dcda1185436fe141f7749120a303721813\");\n-\tTEST_HASH_LITERAL(\"blob 3\\0abc\",\n-\t\t\"f2ba8f84ab5c1bce84a7b441cb1959cfc7093b7f\",\n-\t\t\"c1cf6e465077930e88dc5136641d402f72a229ddd996f627d60e9639eaba35a6\");\n-\tTEST_HASH_LITERAL(\"tree 0\\0\",\n-\t\t\"4b825dc642cb6eb9a060e54bf8d69288fbee4904\",\n-\t\t\"6ef19b41225c5369f1c104d45d8d85efa9b057b53b14b4b9b939dd74decc5321\");\n-\n-\tstrbuf_release(&aaaaaaaaaa_100000);\n-\tstrbuf_release(&alphabet_100000);\n-\n-\treturn test_done();\n-}\ndiff --git a/t/unit-tests/u-hash.c b/t/unit-tests/u-hash.c\nnew file mode 100644\nindex 0000000000..c7bac69d03\n--- /dev/null\n+++ b/t/unit-tests/u-hash.c\n@@ -0,0 +1,85 @@\n+#include \"unit-test.h\"\n+#include \"hex.h\"\n+#include \"strbuf.h\"\n+\n+static void check_hash_data(const void *data, size_t data_length,\n+\t\t\t    const char *expected_hashes[])\n+{\n+\tcl_assert(data != NULL);\n+\n+\tfor (size_t i = 1; i < ARRAY_SIZE(hash_algos); i++) {\n+\t\tgit_hash_ctx ctx;\n+\t\tunsigned char hash[GIT_MAX_HEXSZ];\n+\t\tconst struct git_hash_algo *algop = &hash_algos[i];\n+\n+\t\talgop->init_fn(&ctx);\n+\t\talgop->update_fn(&ctx, data, data_length);\n+\t\talgop->final_fn(hash, &ctx);\n+\n+\t\tcl_assert_equal_s(hash_to_hex_algop(hash,algop), expected_hashes[i - 1]);\n+\t}\n+}\n+\n+/* Works with a NUL terminated string. Doesn't work if it should contain a NUL character. */\n+#define TEST_HASH_STR(data, expected_sha1, expected_sha256) { \\\n+\tconst char *expected_hashes[] = { expected_sha1, expected_sha256 }; \\\n+\tcheck_hash_data(data, strlen(data), expected_hashes); \\\n+}\n+\n+/* Only works with a literal string, useful when it contains a NUL character. */\n+#define TEST_HASH_LITERAL(literal, expected_sha1, expected_sha256) { \\\n+\tconst char *expected_hashes[] = { expected_sha1, expected_sha256 }; \\\n+\tcheck_hash_data(literal, (sizeof(literal) - 1), expected_hashes); \\\n+}\n+\n+void test_hash__empty_string(void) TEST_HASH_STR(\"\",\n+\t\"da39a3ee5e6b4b0d3255bfef95601890afd80709\",\n+\t\"e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855\")\n+\n+void test_hash__single_character(void) TEST_HASH_STR(\"a\",\n+\t\"86f7e437faa5a7fce15d1ddcb9eaeaea377667b8\",\n+\t\"ca978112ca1bbdcafac231b39a23dc4da786eff8147c4e72b9807785afee48bb\")\n+\n+void test_hash__multi_character(void) TEST_HASH_STR(\"abc\",\n+\t\"a9993e364706816aba3e25717850c26c9cd0d89d\",\n+\t\"ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad\")\n+\n+void test_hash__message_digest(void) TEST_HASH_STR(\"message digest\",\n+\t\"c12252ceda8be8994d5fa0290a47231c1d16aae3\",\n+\t\"f7846f55cf23e14eebeab5b4e1550cad5b509e3348fbc4efa3a1413d393cb650\")\n+\n+void test_hash__alphabet(void) TEST_HASH_STR(\"abcdefghijklmnopqrstuvwxyz\",\n+\t\"32d10c7b8cf96570ca04ce37f2a19d84240d3a89\",\n+\t\"71c480df93d6ae2f1efad1447c66c9525e316218cf51fc8d9ed832f2daf18b73\")\n+\n+void test_hash__aaaaaaaaaa_100000(void)\n+{\n+\tstruct strbuf aaaaaaaaaa_100000 = STRBUF_INIT;\n+\tstrbuf_addstrings(&aaaaaaaaaa_100000, \"aaaaaaaaaa\", 100000);\n+\tTEST_HASH_STR(aaaaaaaaaa_100000.buf,\n+\t\t\"34aa973cd4c4daa4f61eeb2bdbad27316534016f\",\n+\t\t\"cdc76e5c9914fb9281a1c7e284d73e67f1809a48a497200e046d39ccc7112cd0\")\n+\tstrbuf_release(&aaaaaaaaaa_100000);\n+}\n+\n+void test_hash__alphabet_100000(void)\n+{\n+\tstruct strbuf alphabet_100000 = STRBUF_INIT;\n+\tstrbuf_addstrings(&alphabet_100000, \"abcdefghijklmnopqrstuvwxyz\", 100000);\n+\tTEST_HASH_STR(alphabet_100000.buf,\n+\t\t\"e7da7c55b3484fdf52aebec9cbe7b85a98f02fd4\",\n+\t\t\"e406ba321ca712ad35a698bf0af8d61fc4dc40eca6bdcea4697962724ccbde35\")\n+\tstrbuf_release(&alphabet_100000);\n+}\n+\n+void test_hash__zero_blob_literal(void) TEST_HASH_LITERAL(\"blob 0\\0\",\n+\t\"e69de29bb2d1d6434b8b29ae775ad8c2e48c5391\",\n+\t\"473a0f4c3be8a93681a267e3b1e9a7dcda1185436fe141f7749120a303721813\")\n+\n+void test_hash__three_blob_literal(void) TEST_HASH_LITERAL(\"blob 3\\0abc\",\n+\t\"f2ba8f84ab5c1bce84a7b441cb1959cfc7093b7f\",\n+\t\"c1cf6e465077930e88dc5136641d402f72a229ddd996f627d60e9639eaba35a6\")\n+\n+void test_hash__zero_tree_literal(void) TEST_HASH_LITERAL(\"tree 0\\0\",\n+\t\"4b825dc642cb6eb9a060e54bf8d69288fbee4904\",\n+\t\"6ef19b41225c5369f1c104d45d8d85efa9b057b53b14b4b9b939dd74decc5321\")\n-- \n2.34.1\n\n"},{"id":"510103","messageId":"xmqq7c76trpa.fsf@gitster.g","threadId":"62755","inReplyTo":"20250107091932.126673-2-kuforiji98@gmail.com","subject":"Re: [PATCH 1/2] t/unit-tests: match functions signature with trailing code","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-01-07T18:16:33Z","receivedAt":"2025-01-07T18:16:36Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Seyi Kuforiji <kuforiji98@gmail.com> writes:\n\n> The `generate-clar-decls.sh` script extracts signatures of test\n> functions from our unit tests, which will later get used by the clar to\n> automatically wire up tests. The sed command only matches lines that\n> ended immediately after `void)`, causing it to miss declarations with\n> additional content such as comments or annotations.\n>\n> Relax the regular expression by making it match lines with trailing data\n> after the function signature. This ensures that all valid function\n> declarations are captured and formatted as `extern` declarations\n> regardless of their formatting style, improving the robustness of the\n> script when parsing `$suite` files.\n>\n> This will be used in subsequent commits to match and capture the\n> function signature correctly, regardless of any trailing content.\n\nI am not sure if this is going in the right direction, though.\n\nEspecially for things like test suites that are looked at and worked\non only by develoeprs *and* these tools, being uniform and consistent\nweighs more than being more flexible.\n\nLet me state it in another way.  How many of the existing test\npieces are picked up by the current pattern, and among them how many\nof them would see vast improvements if they are allowed to have\narbitrary garbage after their \"I do not take any arguments\" function\nsignature?  Are new tests you are migrating from outside the clar\nworld lose a lot if they are no longer allowed to have comments\nthere, or would it be suffice to have the comments before the\nfunctions (which many of our function definition do anyway)?\n\nA quick peek at [PATCH 2/2] tells me that this is not even something\nthat would make it easier to port the existing tests by allowing\nmore straight line-by-line copies or something.  The patch splits\nmany in-line test pieces in the \"main\" into separate functions, and\nit does so in a rather unusual format, e.g.,\n\n  void test_hash__multi_character(void) TEST_HASH_STR(\"abc\",\n          \"a9993e364706816aba3e25717850c26c9cd0d89d\",\n          \"ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad\")\n\nwhere TEST_HASH_STR() expands to the function body that starts with\na \"{\" and ends with a \"}\".  It can well be written more like\n\n    void test_hash__multi_character(void)\n    {\n\tTEST_HASH_STR(\"abc\",\n        \t\"a9993e364706816aba3e25717850c26c9cd0d89d\",\n\t\t\"ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad\");\n    }\n\nand we do not need this step at all if we did so.  Such a construct\nwould be a lot friendlier to the editors that auto-indent, too.\n\nSo, I do not quite see much value in this particular change.\n\n> Mentored-by: Patrick Steinhardt <ps@pks.im>\n> Signed-off-by: Seyi Kuforiji <kuforiji98@gmail.com>\n> ---\n>  t/unit-tests/generate-clar-decls.sh | 2 +-\n>  1 file changed, 1 insertion(+), 1 deletion(-)\n>\n> diff --git a/t/unit-tests/generate-clar-decls.sh b/t/unit-tests/generate-clar-decls.sh\n> index 3b315c64b3..02e45cf0ba 100755\n> --- a/t/unit-tests/generate-clar-decls.sh\n> +++ b/t/unit-tests/generate-clar-decls.sh\n> @@ -14,6 +14,6 @@ do\n>  \tsuite_name=$(basename \"$suite\")\n>  \tsuite_name=${suite_name%.c}\n>  \tsuite_name=${suite_name#u-}\n> -\tsed -ne \"s/^\\(void test_${suite_name}__[a-zA-Z_0-9][a-zA-Z_0-9]*(void)\\)$/extern \\1;/p\" \"$suite\" ||\n> +\tsed -ne \"s/^\\(void test_${suite_name}__[a-zA-Z_0-9][a-zA-Z_0-9]*(void)\\).*/extern \\1;/p\" \"$suite\" ||\n>  \texit 1\n>  done >\"$OUTPUT\"\n> --\n> 2.34.1\n"},{"id":"510105","messageId":"xmqqv7uqsc03.fsf@gitster.g","threadId":"62755","inReplyTo":"xmqq7c76trpa.fsf@gitster.g","subject":"Re: [PATCH 1/2] t/unit-tests: match functions signature with trailing code","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-01-07T18:41:00Z","receivedAt":"2025-01-07T18:41:04Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> A quick peek at [PATCH 2/2] tells me that this is not even something\n> that would make it easier to port the existing tests by allowing\n> more straight line-by-line copies or something.  The patch splits\n> many in-line test pieces in the \"main\" into separate functions, and\n> it does so in a rather unusual format, e.g.,\n>\n>   void test_hash__multi_character(void) TEST_HASH_STR(\"abc\",\n>           \"a9993e364706816aba3e25717850c26c9cd0d89d\",\n>           \"ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad\")\n>\n> where TEST_HASH_STR() expands to the function body that starts with\n> a \"{\" and ends with a \"}\".  It can well be written more like\n>\n>     void test_hash__multi_character(void)\n>     {\n> \tTEST_HASH_STR(\"abc\",\n>         \t\"a9993e364706816aba3e25717850c26c9cd0d89d\",\n> \t\t\"ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad\");\n>     }\n>\n> and we do not need this step at all if we did so.  Such a construct\n> would be a lot friendlier to the editors that auto-indent, too.\n>\n> So, I do not quite see much value in this particular change.\n\nHaving said that, if this were more like that you write a series of\n\n    DEF_HASH_TEST(multi_character, \"abc\", \"a9993e...\", \"ba7816bf...\")\n\nand they expand to\n\n    void test_hash__multi_character(void)\n    {\n\tconst char *expected[] = {\"a9993e...\", \"ba7816bf...\"};\n\tcheck_hash_data(\"abc\", strlen(\"abc\"), expected);\n    }\n\nthen a preparatory step like this patch _might_ be justifiable.  You\nmay want to avoid having to write too many boilerplate, and a\nspecial rule to find \"DEF_HASH_TEST(name, ...)\" and it might make\nsense to add support to extract the name of the test function being\ndefined by the macro automatically.\n\nNot that I think such a sequence of DEF_HASH_TEST(), one per line,\nis an improvement at all (it also is unfriendly to editors that\nauto-indent the same way as your original version).  I just wanted\nto say that a change to the pattern to pick up the function name may\nbe justifiable if it were so.\n\nThanks.\n"},{"id":"510144","messageId":"Z34XvPjhY15MFHrT@pks.im","threadId":"62755","inReplyTo":"xmqq7c76trpa.fsf@gitster.g","subject":"Re: [PATCH 1/2] t/unit-tests: match functions signature with trailing code","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-01-08T06:14:20Z","receivedAt":"2025-01-08T06:14:26Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Tue, Jan 07, 2025 at 10:16:33AM -0800, Junio C Hamano wrote:\n> Seyi Kuforiji <kuforiji98@gmail.com> writes:\n> \n> > The `generate-clar-decls.sh` script extracts signatures of test\n> > functions from our unit tests, which will later get used by the clar to\n> > automatically wire up tests. The sed command only matches lines that\n> > ended immediately after `void)`, causing it to miss declarations with\n> > additional content such as comments or annotations.\n> >\n> > Relax the regular expression by making it match lines with trailing data\n> > after the function signature. This ensures that all valid function\n> > declarations are captured and formatted as `extern` declarations\n> > regardless of their formatting style, improving the robustness of the\n> > script when parsing `$suite` files.\n> >\n> > This will be used in subsequent commits to match and capture the\n> > function signature correctly, regardless of any trailing content.\n> \n> I am not sure if this is going in the right direction, though.\n> \n> Especially for things like test suites that are looked at and worked\n> on only by develoeprs *and* these tools, being uniform and consistent\n> weighs more than being more flexible.\n> \n> Let me state it in another way.  How many of the existing test\n> pieces are picked up by the current pattern, and among them how many\n> of them would see vast improvements if they are allowed to have\n> arbitrary garbage after their \"I do not take any arguments\" function\n> signature?  Are new tests you are migrating from outside the clar\n> world lose a lot if they are no longer allowed to have comments\n> there, or would it be suffice to have the comments before the\n> functions (which many of our function definition do anyway)?\n> \n> A quick peek at [PATCH 2/2] tells me that this is not even something\n> that would make it easier to port the existing tests by allowing\n> more straight line-by-line copies or something.  The patch splits\n> many in-line test pieces in the \"main\" into separate functions, and\n> it does so in a rather unusual format, e.g.,\n> \n>   void test_hash__multi_character(void) TEST_HASH_STR(\"abc\",\n>           \"a9993e364706816aba3e25717850c26c9cd0d89d\",\n>           \"ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad\")\n> \n> where TEST_HASH_STR() expands to the function body that starts with\n> a \"{\" and ends with a \"}\".  It can well be written more like\n> \n>     void test_hash__multi_character(void)\n>     {\n> \tTEST_HASH_STR(\"abc\",\n>         \t\"a9993e364706816aba3e25717850c26c9cd0d89d\",\n> \t\t\"ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad\");\n>     }\n> \n> and we do not need this step at all if we did so.  Such a construct\n> would be a lot friendlier to the editors that auto-indent, too.\n> \n> So, I do not quite see much value in this particular change.\n\nYeah. This was something I proposed, but I already mentioned to Seyi\nthat I'm not all that happy with the outcome as it has a couple of\ndownsides, for example broken syntax highlighting in lots of editors. I\nsaid he can send that version to the mailing list anyway and get some\nfeedback on it to figure out whether my discomfort with my own idea is\nwarranted or not. And your comment here basically confirms that my idea\nwasn't that great after all :)\n\nSo I agree with you, let's scrap the idea and have proper function\nbodies instead.\n\nPatrick\n"},{"id":"510149","messageId":"CAGedMtcNpYBRsr9b8-ftbs6JFdp58wNGyYssiF1s0MEmziDtxw@mail.gmail.com","threadId":"62755","inReplyTo":"Z34XvPjhY15MFHrT@pks.im","subject":"Re: [PATCH 1/2] t/unit-tests: match functions signature with trailing code","fromName":"Seyi Chamber","fromEmail":"kuforiji98@gmail.com","sentAt":"2025-01-08T08:31:03Z","receivedAt":"2025-01-08T08:31:15Z","isPatch":true,"sender":{"key":"kuforiji98@gmail.com","avatar":"https://avatars.githubusercontent.com/u/94905626?v=4"},"body":"On Wed, 8 Jan 2025 at 07:14, Patrick Steinhardt <ps@pks.im> wrote:\n>\n> On Tue, Jan 07, 2025 at 10:16:33AM -0800, Junio C Hamano wrote:\n> > Seyi Kuforiji <kuforiji98@gmail.com> writes:\n> >\n> > > The `generate-clar-decls.sh` script extracts signatures of test\n> > > functions from our unit tests, which will later get used by the clar to\n> > > automatically wire up tests. The sed command only matches lines that\n> > > ended immediately after `void)`, causing it to miss declarations with\n> > > additional content such as comments or annotations.\n> > >\n> > > Relax the regular expression by making it match lines with trailing data\n> > > after the function signature. This ensures that all valid function\n> > > declarations are captured and formatted as `extern` declarations\n> > > regardless of their formatting style, improving the robustness of the\n> > > script when parsing `$suite` files.\n> > >\n> > > This will be used in subsequent commits to match and capture the\n> > > function signature correctly, regardless of any trailing content.\n> >\n> > I am not sure if this is going in the right direction, though.\n> >\n> > Especially for things like test suites that are looked at and worked\n> > on only by develoeprs *and* these tools, being uniform and consistent\n> > weighs more than being more flexible.\n> >\n> > Let me state it in another way.  How many of the existing test\n> > pieces are picked up by the current pattern, and among them how many\n> > of them would see vast improvements if they are allowed to have\n> > arbitrary garbage after their \"I do not take any arguments\" function\n> > signature?  Are new tests you are migrating from outside the clar\n> > world lose a lot if they are no longer allowed to have comments\n> > there, or would it be suffice to have the comments before the\n> > functions (which many of our function definition do anyway)?\n> >\n> > A quick peek at [PATCH 2/2] tells me that this is not even something\n> > that would make it easier to port the existing tests by allowing\n> > more straight line-by-line copies or something.  The patch splits\n> > many in-line test pieces in the \"main\" into separate functions, and\n> > it does so in a rather unusual format, e.g.,\n> >\n> >   void test_hash__multi_character(void) TEST_HASH_STR(\"abc\",\n> >           \"a9993e364706816aba3e25717850c26c9cd0d89d\",\n> >           \"ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad\")\n> >\n> > where TEST_HASH_STR() expands to the function body that starts with\n> > a \"{\" and ends with a \"}\".  It can well be written more like\n> >\n> >     void test_hash__multi_character(void)\n> >     {\n> >       TEST_HASH_STR(\"abc\",\n> >               \"a9993e364706816aba3e25717850c26c9cd0d89d\",\n> >               \"ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad\");\n> >     }\n> >\n> > and we do not need this step at all if we did so.  Such a construct\n> > would be a lot friendlier to the editors that auto-indent, too.\n> >\n> > So, I do not quite see much value in this particular change.\n>\n> Yeah. This was something I proposed, but I already mentioned to Seyi\n> that I'm not all that happy with the outcome as it has a couple of\n> downsides, for example broken syntax highlighting in lots of editors. I\n> said he can send that version to the mailing list anyway and get some\n> feedback on it to figure out whether my discomfort with my own idea is\n> warranted or not. And your comment here basically confirms that my idea\n> wasn't that great after all :)\n>\n> So I agree with you, let's scrap the idea and have proper function\n> bodies instead.\n>\n> Patrick\n\nThank you for the feedback and insights. I'll update the patch to use\nstandard function bodies.\n\nThanks\nSeyi\n"},{"id":"510153","messageId":"20250108120339.225596-1-kuforiji98@gmail.com","threadId":"62755","inReplyTo":"20250107091932.126673-1-kuforiji98@gmail.com","subject":"[PATCH v2 0/1] t/unit-tests: convert hash to use clar test framework","fromName":"Seyi Kuforiji","fromEmail":"kuforiji98@gmail.com","sentAt":"2025-01-08T12:03:38Z","receivedAt":"2025-01-08T12:03:57Z","isPatch":true,"sender":{"key":"kuforiji98@gmail.com","avatar":"https://avatars.githubusercontent.com/u/94905626?v=4"},"body":"Hello,\n\nThis small patch series transitions the existing unit test file t-hash.c\nto the Clar testing framework. This change is part of our ongoing effort\nto standardize our testing approach and enhance maintainability.\n\nchanges in v2:\n- Some small fixes were made to the macros and test functions\n- Link to v1: https://public-inbox.org/git/20250107091932.126673-1-kuforiji98@gmail.com/T/#t\n\nThanks\nSeyi\n\nSeyi Kuforiji (1):\n  t/unit-tests: convert hash to use clar test framework\n\n Makefile                            |  2 +-\n t/meson.build                       |  2 +-\n t/unit-tests/{t-hash.c => u-hash.c} | 75 +++++++++++++++++++----------\n 3 files changed, 52 insertions(+), 27 deletions(-)\n rename t/unit-tests/{t-hash.c => u-hash.c} (79%)\n\nRange-diff against v1:\n-:  ---------- > 1:  6fde57893d t/unit-tests: convert hash to use clar test framework\n-- \n2.34.1\n\n"},{"id":"510154","messageId":"20250108120339.225596-2-kuforiji98@gmail.com","threadId":"62755","inReplyTo":"20250108120339.225596-1-kuforiji98@gmail.com","subject":"[PATCH v2 1/1] t/unit-tests: convert hash to use clar test framework","fromName":"Seyi Kuforiji","fromEmail":"kuforiji98@gmail.com","sentAt":"2025-01-08T12:03:39Z","receivedAt":"2025-01-08T12:04:03Z","isPatch":true,"sender":{"key":"kuforiji98@gmail.com","avatar":"https://avatars.githubusercontent.com/u/94905626?v=4"},"body":"Adapt the hash test functions to clar framework by using clar\nassertions where necessary. Following the consensus to convert\nthe unit-tests scripts found in the t/unit-tests folder to clar driven by\nPatrick Steinhardt. Test functions are structured as a standalone to\ntest individual hash string and literal case.\n\nMentored-by: Patrick Steinhardt <ps@pks.im>\nSigned-off-by: Seyi Kuforiji <kuforiji98@gmail.com>\n---\n Makefile                            |  2 +-\n t/meson.build                       |  2 +-\n t/unit-tests/{t-hash.c => u-hash.c} | 75 +++++++++++++++++++----------\n 3 files changed, 52 insertions(+), 27 deletions(-)\n rename t/unit-tests/{t-hash.c => u-hash.c} (79%)\n\ndiff --git a/Makefile b/Makefile\nindex 97e8385b66..d3011e30f7 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -1338,6 +1338,7 @@ THIRD_PARTY_SOURCES += $(UNIT_TEST_DIR)/clar/%\n THIRD_PARTY_SOURCES += $(UNIT_TEST_DIR)/clar/clar/%\n \n CLAR_TEST_SUITES += u-ctype\n+CLAR_TEST_SUITES += u-hash\n CLAR_TEST_SUITES += u-strvec\n CLAR_TEST_PROG = $(UNIT_TEST_BIN)/unit-tests$(X)\n CLAR_TEST_OBJS = $(patsubst %,$(UNIT_TEST_DIR)/%.o,$(CLAR_TEST_SUITES))\n@@ -1345,7 +1346,6 @@ CLAR_TEST_OBJS += $(UNIT_TEST_DIR)/clar/clar.o\n CLAR_TEST_OBJS += $(UNIT_TEST_DIR)/unit-test.o\n \n UNIT_TEST_PROGRAMS += t-example-decorate\n-UNIT_TEST_PROGRAMS += t-hash\n UNIT_TEST_PROGRAMS += t-hashmap\n UNIT_TEST_PROGRAMS += t-mem-pool\n UNIT_TEST_PROGRAMS += t-oid-array\ndiff --git a/t/meson.build b/t/meson.build\nindex 602ebfe6a2..d722bc7dff 100644\n--- a/t/meson.build\n+++ b/t/meson.build\n@@ -1,6 +1,7 @@\n clar_test_suites = [\n   'unit-tests/u-ctype.c',\n   'unit-tests/u-strvec.c',\n+  'unit-tests/u-hash.c',\n ]\n \n clar_sources = [\n@@ -41,7 +42,6 @@ test('unit-tests', clar_unit_tests)\n \n unit_test_programs = [\n   'unit-tests/t-example-decorate.c',\n-  'unit-tests/t-hash.c',\n   'unit-tests/t-hashmap.c',\n   'unit-tests/t-mem-pool.c',\n   'unit-tests/t-oid-array.c',\ndiff --git a/t/unit-tests/t-hash.c b/t/unit-tests/u-hash.c\nsimilarity index 79%\nrename from t/unit-tests/t-hash.c\nrename to t/unit-tests/u-hash.c\nindex e62647019b..e5e2d2e033 100644\n--- a/t/unit-tests/t-hash.c\n+++ b/t/unit-tests/u-hash.c\n@@ -1,14 +1,11 @@\n-#include \"test-lib.h\"\n+#include \"unit-test.h\"\n #include \"hex.h\"\n #include \"strbuf.h\"\n \n static void check_hash_data(const void *data, size_t data_length,\n \t\t\t    const char *expected_hashes[])\n {\n-\tif (!check(data != NULL)) {\n-\t\ttest_msg(\"BUG: NULL data pointer provided\");\n-\t\treturn;\n-\t}\n+\tcl_assert(data != NULL);\n \n \tfor (size_t i = 1; i < ARRAY_SIZE(hash_algos); i++) {\n \t\tgit_hash_ctx ctx;\n@@ -19,66 +16,94 @@ static void check_hash_data(const void *data, size_t data_length,\n \t\talgop->update_fn(&ctx, data, data_length);\n \t\talgop->final_fn(hash, &ctx);\n \n-\t\tif (!check_str(hash_to_hex_algop(hash, algop), expected_hashes[i - 1]))\n-\t\t\ttest_msg(\"result does not match with the expected for %s\\n\", hash_algos[i].name);\n+\t\tcl_assert_equal_s(hash_to_hex_algop(hash,algop), expected_hashes[i - 1]);\n \t}\n }\n \n /* Works with a NUL terminated string. Doesn't work if it should contain a NUL character. */\n #define TEST_HASH_STR(data, expected_sha1, expected_sha256) do { \\\n \t\tconst char *expected_hashes[] = { expected_sha1, expected_sha256 }; \\\n-\t\tTEST(check_hash_data(data, strlen(data), expected_hashes), \\\n-\t\t     \"SHA1 and SHA256 (%s) works\", #data); \\\n-\t} while (0)\n+\t\tcheck_hash_data(data, strlen(data), expected_hashes); \\\n+\t} while(0)\n \n /* Only works with a literal string, useful when it contains a NUL character. */\n #define TEST_HASH_LITERAL(literal, expected_sha1, expected_sha256) do { \\\n \t\tconst char *expected_hashes[] = { expected_sha1, expected_sha256 }; \\\n-\t\tTEST(check_hash_data(literal, (sizeof(literal) - 1), expected_hashes), \\\n-\t\t     \"SHA1 and SHA256 (%s) works\", #literal); \\\n-\t} while (0)\n+\t\tcheck_hash_data(literal, (sizeof(literal) - 1), expected_hashes); \\\n+\t} while(0)\n \n-int cmd_main(int argc UNUSED, const char **argv UNUSED)\n+void test_hash__empty_string(void)\n {\n-\tstruct strbuf aaaaaaaaaa_100000 = STRBUF_INIT;\n-\tstruct strbuf alphabet_100000 = STRBUF_INIT;\n-\n-\tstrbuf_addstrings(&aaaaaaaaaa_100000, \"aaaaaaaaaa\", 100000);\n-\tstrbuf_addstrings(&alphabet_100000, \"abcdefghijklmnopqrstuvwxyz\", 100000);\n-\n \tTEST_HASH_STR(\"\",\n \t\t\"da39a3ee5e6b4b0d3255bfef95601890afd80709\",\n \t\t\"e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855\");\n+}\n+\n+void test_hash__single_character(void)\n+{\n \tTEST_HASH_STR(\"a\",\n \t\t\"86f7e437faa5a7fce15d1ddcb9eaeaea377667b8\",\n \t\t\"ca978112ca1bbdcafac231b39a23dc4da786eff8147c4e72b9807785afee48bb\");\n+}\n+\n+void test_hash__multi_character(void)\n+{\n \tTEST_HASH_STR(\"abc\",\n \t\t\"a9993e364706816aba3e25717850c26c9cd0d89d\",\n \t\t\"ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad\");\n+}\n+\n+void test_hash__message_digest(void)\n+{\n \tTEST_HASH_STR(\"message digest\",\n \t\t\"c12252ceda8be8994d5fa0290a47231c1d16aae3\",\n \t\t\"f7846f55cf23e14eebeab5b4e1550cad5b509e3348fbc4efa3a1413d393cb650\");\n+}\n+\n+void test_hash__alphabet(void)\n+{\n \tTEST_HASH_STR(\"abcdefghijklmnopqrstuvwxyz\",\n \t\t\"32d10c7b8cf96570ca04ce37f2a19d84240d3a89\",\n \t\t\"71c480df93d6ae2f1efad1447c66c9525e316218cf51fc8d9ed832f2daf18b73\");\n+}\n+\n+void test_hash__aaaaaaaaaa_100000(void)\n+{\n+\tstruct strbuf aaaaaaaaaa_100000 = STRBUF_INIT;\n+\tstrbuf_addstrings(&aaaaaaaaaa_100000, \"aaaaaaaaaa\", 100000);\n \tTEST_HASH_STR(aaaaaaaaaa_100000.buf,\n \t\t\"34aa973cd4c4daa4f61eeb2bdbad27316534016f\",\n \t\t\"cdc76e5c9914fb9281a1c7e284d73e67f1809a48a497200e046d39ccc7112cd0\");\n+\tstrbuf_release(&aaaaaaaaaa_100000);\n+}\n+\n+void test_hash__alphabet_100000(void)\n+{\n+\tstruct strbuf alphabet_100000 = STRBUF_INIT;\n+\tstrbuf_addstrings(&alphabet_100000, \"abcdefghijklmnopqrstuvwxyz\", 100000);\n \tTEST_HASH_STR(alphabet_100000.buf,\n \t\t\"e7da7c55b3484fdf52aebec9cbe7b85a98f02fd4\",\n \t\t\"e406ba321ca712ad35a698bf0af8d61fc4dc40eca6bdcea4697962724ccbde35\");\n+\tstrbuf_release(&alphabet_100000);\n+}\n+\n+void test_hash__zero_blob_literal(void)\n+{\n \tTEST_HASH_LITERAL(\"blob 0\\0\",\n \t\t\"e69de29bb2d1d6434b8b29ae775ad8c2e48c5391\",\n \t\t\"473a0f4c3be8a93681a267e3b1e9a7dcda1185436fe141f7749120a303721813\");\n+}\n+\n+void test_hash__three_blob_literal(void)\n+{\n \tTEST_HASH_LITERAL(\"blob 3\\0abc\",\n \t\t\"f2ba8f84ab5c1bce84a7b441cb1959cfc7093b7f\",\n \t\t\"c1cf6e465077930e88dc5136641d402f72a229ddd996f627d60e9639eaba35a6\");\n+}\n+\n+void test_hash__zero_tree_literal(void)\n+{\n \tTEST_HASH_LITERAL(\"tree 0\\0\",\n \t\t\"4b825dc642cb6eb9a060e54bf8d69288fbee4904\",\n \t\t\"6ef19b41225c5369f1c104d45d8d85efa9b057b53b14b4b9b939dd74decc5321\");\n-\n-\tstrbuf_release(&aaaaaaaaaa_100000);\n-\tstrbuf_release(&alphabet_100000);\n-\n-\treturn test_done();\n }\n-- \n2.34.1\n\n"},{"id":"510162","messageId":"xmqqcygxpbpy.fsf@gitster.g","threadId":"62755","inReplyTo":"Z34XvPjhY15MFHrT@pks.im","subject":"Re: [PATCH 1/2] t/unit-tests: match functions signature with trailing code","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-01-08T15:27:37Z","receivedAt":"2025-01-08T15:27:40Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Patrick Steinhardt <ps@pks.im> writes:\n\n> So I agree with you, let's scrap the idea and have proper function\n> bodies instead.\n\nYup, sometimes, simple, stupid, and good enough is the way to go.\n\nWe could do\n\n-- >8 --\n\n#define T(testname, input, expect1, expect256) \\\n\tvoid test_hash__ ## testname(void) \\\n\t{ \\\n\t\tconst char *expect[] = { expect1, expect256 }; \\\n\t\tcheck_hash_data(input, strlen(input), expect); \\\n\t} extern void test_hash__ ## testname()\n\nT(empty_string, \"\", \"da39...\", \"e3b0c4...\");\nT(single_character, \"a\", \"86f7e4...\", \"ca97811...\");\n\n-- 8< --\n\nwhich may not upset syntax-aware editors too much.\n\nUnless there are more than several dozens of them, I do not think it\nis worth it, though ;-)\n"},{"id":"510163","messageId":"xmqq8qrlpbnx.fsf@gitster.g","threadId":"62755","inReplyTo":"20250108120339.225596-1-kuforiji98@gmail.com","subject":"Re: [PATCH v2 0/1] t/unit-tests: convert hash to use clar test framework","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-01-08T15:28:50Z","receivedAt":"2025-01-08T15:28:53Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Seyi Kuforiji <kuforiji98@gmail.com> writes:\n\n> Hello,\n>\n> This small patch series transitions the existing unit test file t-hash.c\n> to the Clar testing framework. This change is part of our ongoing effort\n> to standardize our testing approach and enhance maintainability.\n\nThanks; this is no longer a series but a single patch ;-)\n"},{"id":"510164","messageId":"xmqqv7upnwsp.fsf@gitster.g","threadId":"62755","inReplyTo":"20250108120339.225596-2-kuforiji98@gmail.com","subject":"Re: [PATCH v2 1/1] t/unit-tests: convert hash to use clar test framework","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-01-08T15:35:18Z","receivedAt":"2025-01-08T15:35:20Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Seyi Kuforiji <kuforiji98@gmail.com> writes:\n\n>  CLAR_TEST_SUITES += u-ctype\n> +CLAR_TEST_SUITES += u-hash\n>  CLAR_TEST_SUITES += u-strvec\n\nThis is inserted in the middle, presumably because a list without\ninherent ordering is by default maintained as a lexicographically\nsorted list.\n\n> diff --git a/t/meson.build b/t/meson.build\n> index 602ebfe6a2..d722bc7dff 100644\n> --- a/t/meson.build\n> +++ b/t/meson.build\n> @@ -1,6 +1,7 @@\n>  clar_test_suites = [\n>    'unit-tests/u-ctype.c',\n>    'unit-tests/u-strvec.c',\n> +  'unit-tests/u-hash.c',\n>  ]\n\nSo, shouldn't we do the same here?\n\n> diff --git a/t/unit-tests/t-hash.c b/t/unit-tests/u-hash.c\n> similarity index 79%\n> rename from t/unit-tests/t-hash.c\n> rename to t/unit-tests/u-hash.c\n> ...\n>  #define TEST_HASH_STR(data, expected_sha1, expected_sha256) do { \\\n>  \t\tconst char *expected_hashes[] = { expected_sha1, expected_sha256 }; \\\n> -\t\tTEST(check_hash_data(data, strlen(data), expected_hashes), \\\n> -\t\t     \"SHA1 and SHA256 (%s) works\", #data); \\\n> -\t} while (0)\n> +\t\tcheck_hash_data(data, strlen(data), expected_hashes); \\\n> +\t} while(0)\n\nUnwanted droppage of SP between \"while\" and \"(0)\".\n\n>  /* Only works with a literal string, useful when it contains a NUL character. */\n>  #define TEST_HASH_LITERAL(literal, expected_sha1, expected_sha256) do { \\\n>  \t\tconst char *expected_hashes[] = { expected_sha1, expected_sha256 }; \\\n> -\t\tTEST(check_hash_data(literal, (sizeof(literal) - 1), expected_hashes), \\\n> -\t\t     \"SHA1 and SHA256 (%s) works\", #literal); \\\n> -\t} while (0)\n> +\t\tcheck_hash_data(literal, (sizeof(literal) - 1), expected_hashes); \\\n> +\t} while(0)\n\nDitto.\n\n> -int cmd_main(int argc UNUSED, const char **argv UNUSED)\n> +void test_hash__empty_string(void)\n>  {\n> -\tstruct strbuf aaaaaaaaaa_100000 = STRBUF_INIT;\n> -\tstruct strbuf alphabet_100000 = STRBUF_INIT;\n> -\n> -\tstrbuf_addstrings(&aaaaaaaaaa_100000, \"aaaaaaaaaa\", 100000);\n> -\tstrbuf_addstrings(&alphabet_100000, \"abcdefghijklmnopqrstuvwxyz\", 100000);\n> -\n>  \tTEST_HASH_STR(\"\",\n>  \t\t\"da39a3ee5e6b4b0d3255bfef95601890afd80709\",\n>  \t\t\"e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855\");\n> +}\n> +\n> +void test_hash__single_character(void)\n> +{\n>  \tTEST_HASH_STR(\"a\",\n>  \t\t\"86f7e437faa5a7fce15d1ddcb9eaeaea377667b8\",\n>  \t\t\"ca978112ca1bbdcafac231b39a23dc4da786eff8147c4e72b9807785afee48bb\");\n> +}\n\nOK.\n\nI'll skip the rest as I expect they would be faithful conversions.\n\nThanks.\n\n"},{"id":"510172","messageId":"Z36kqlcKl20AkJvW@pks.im","threadId":"62755","inReplyTo":"xmqqcygxpbpy.fsf@gitster.g","subject":"Re: [PATCH 1/2] t/unit-tests: match functions signature with trailing code","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-01-08T16:15:38Z","receivedAt":"2025-01-08T16:15:41Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Wed, Jan 08, 2025 at 07:27:37AM -0800, Junio C Hamano wrote:\n> Patrick Steinhardt <ps@pks.im> writes:\n> \n> > So I agree with you, let's scrap the idea and have proper function\n> > bodies instead.\n> \n> Yup, sometimes, simple, stupid, and good enough is the way to go.\n> \n> We could do\n> \n> -- >8 --\n> \n> #define T(testname, input, expect1, expect256) \\\n> \tvoid test_hash__ ## testname(void) \\\n> \t{ \\\n> \t\tconst char *expect[] = { expect1, expect256 }; \\\n> \t\tcheck_hash_data(input, strlen(input), expect); \\\n> \t} extern void test_hash__ ## testname()\n> \n> T(empty_string, \"\", \"da39...\", \"e3b0c4...\");\n> T(single_character, \"a\", \"86f7e4...\", \"ca97811...\");\n> \n> -- 8< --\n> \n> which may not upset syntax-aware editors too much.\n> \n> Unless there are more than several dozens of them, I do not think it\n> is worth it, though ;-)\n\nAgreed, I'd go with the simple solution for now, which is to have\nfunction bodies.\n\nPatrick\n"},{"id":"510217","messageId":"CAGedMtdJgM+vRryKLz5BKuQSBreHOc+q=rexciPB2WZ4aT3=YQ@mail.gmail.com","threadId":"62755","inReplyTo":"xmqq8qrlpbnx.fsf@gitster.g","subject":"Re: [PATCH v2 0/1] t/unit-tests: convert hash to use clar test framework","fromName":"Seyi Chamber","fromEmail":"kuforiji98@gmail.com","sentAt":"2025-01-09T07:21:50Z","receivedAt":"2025-01-09T07:22:05Z","isPatch":true,"sender":{"key":"kuforiji98@gmail.com","avatar":"https://avatars.githubusercontent.com/u/94905626?v=4"},"body":"On Wed, 8 Jan 2025 at 16:28, Junio C Hamano <gitster@pobox.com> wrote:\n>\n> Seyi Kuforiji <kuforiji98@gmail.com> writes:\n>\n> > Hello,\n> >\n> > This small patch series transitions the existing unit test file t-hash.c\n> > to the Clar testing framework. This change is part of our ongoing effort\n> > to standardize our testing approach and enhance maintainability.\n>\n> Thanks; this is no longer a series but a single patch ;-)\n\nYou're absolutely right.Thank you for pointing that out :), I'll make\nsure to update my phrasing in future submissions.\n\nThanks\nSeyi\n"},{"id":"510218","messageId":"CAGedMtd8GxYHj_N9XRwFb11jyRxk4qFASoKHw8iU2KWMPfucoA@mail.gmail.com","threadId":"62755","inReplyTo":"xmqqv7upnwsp.fsf@gitster.g","subject":"Re: [PATCH v2 1/1] t/unit-tests: convert hash to use clar test framework","fromName":"Seyi Chamber","fromEmail":"kuforiji98@gmail.com","sentAt":"2025-01-09T07:30:49Z","receivedAt":"2025-01-09T07:31:03Z","isPatch":true,"sender":{"key":"kuforiji98@gmail.com","avatar":"https://avatars.githubusercontent.com/u/94905626?v=4"},"body":"On Wed, 8 Jan 2025 at 16:35, Junio C Hamano <gitster@pobox.com> wrote:\n>\n> Seyi Kuforiji <kuforiji98@gmail.com> writes:\n>\n> >  CLAR_TEST_SUITES += u-ctype\n> > +CLAR_TEST_SUITES += u-hash\n> >  CLAR_TEST_SUITES += u-strvec\n>\n> This is inserted in the middle, presumably because a list without\n> inherent ordering is by default maintained as a lexicographically\n> sorted list.\n>\n> > diff --git a/t/meson.build b/t/meson.build\n> > index 602ebfe6a2..d722bc7dff 100644\n> > --- a/t/meson.build\n> > +++ b/t/meson.build\n> > @@ -1,6 +1,7 @@\n> >  clar_test_suites = [\n> >    'unit-tests/u-ctype.c',\n> >    'unit-tests/u-strvec.c',\n> > +  'unit-tests/u-hash.c',\n> >  ]\n>\n> So, shouldn't we do the same here?\n>\n\nYes, we should. I'll make the necessary adjustment in the next\niteration. Thanks!\n\n> > diff --git a/t/unit-tests/t-hash.c b/t/unit-tests/u-hash.c\n> > similarity index 79%\n> > rename from t/unit-tests/t-hash.c\n> > rename to t/unit-tests/u-hash.c\n> > ...\n> >  #define TEST_HASH_STR(data, expected_sha1, expected_sha256) do { \\\n> >               const char *expected_hashes[] = { expected_sha1, expected_sha256 }; \\\n> > -             TEST(check_hash_data(data, strlen(data), expected_hashes), \\\n> > -                  \"SHA1 and SHA256 (%s) works\", #data); \\\n> > -     } while (0)\n> > +             check_hash_data(data, strlen(data), expected_hashes); \\\n> > +     } while(0)\n>\n> Unwanted droppage of SP between \"while\" and \"(0)\".\n>\n> >  /* Only works with a literal string, useful when it contains a NUL character. */\n> >  #define TEST_HASH_LITERAL(literal, expected_sha1, expected_sha256) do { \\\n> >               const char *expected_hashes[] = { expected_sha1, expected_sha256 }; \\\n> > -             TEST(check_hash_data(literal, (sizeof(literal) - 1), expected_hashes), \\\n> > -                  \"SHA1 and SHA256 (%s) works\", #literal); \\\n> > -     } while (0)\n> > +             check_hash_data(literal, (sizeof(literal) - 1), expected_hashes); \\\n> > +     } while(0)\n>\n> Ditto.\n>\n> > -int cmd_main(int argc UNUSED, const char **argv UNUSED)\n> > +void test_hash__empty_string(void)\n> >  {\n> > -     struct strbuf aaaaaaaaaa_100000 = STRBUF_INIT;\n> > -     struct strbuf alphabet_100000 = STRBUF_INIT;\n> > -\n> > -     strbuf_addstrings(&aaaaaaaaaa_100000, \"aaaaaaaaaa\", 100000);\n> > -     strbuf_addstrings(&alphabet_100000, \"abcdefghijklmnopqrstuvwxyz\", 100000);\n> > -\n> >       TEST_HASH_STR(\"\",\n> >               \"da39a3ee5e6b4b0d3255bfef95601890afd80709\",\n> >               \"e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855\");\n> > +}\n> > +\n> > +void test_hash__single_character(void)\n> > +{\n> >       TEST_HASH_STR(\"a\",\n> >               \"86f7e437faa5a7fce15d1ddcb9eaeaea377667b8\",\n> >               \"ca978112ca1bbdcafac231b39a23dc4da786eff8147c4e72b9807785afee48bb\");\n> > +}\n>\n> OK.\n>\n> I'll skip the rest as I expect they would be faithful conversions.\n>\n> Thanks.\n>\n\nI'll make the required changes, thank you for pointing them out.\n\nThanks\nSeyi\n"},{"id":"510253","messageId":"20250109140952.5267-1-kuforiji98@gmail.com","threadId":"62755","inReplyTo":"20250108120339.225596-1-kuforiji98@gmail.com","subject":"[PATCH v3] t/unit-tests: convert hash to use clar test framework","fromName":"Seyi Kuforiji","fromEmail":"kuforiji98@gmail.com","sentAt":"2025-01-09T14:09:52Z","receivedAt":"2025-01-09T14:10:42Z","isPatch":true,"sender":{"key":"kuforiji98@gmail.com","avatar":"https://avatars.githubusercontent.com/u/94905626?v=4"},"body":"Adapt the hash test functions to clar framework by using clar\nassertions where necessary. Following the consensus to convert\nthe unit-tests scripts found in the t/unit-tests folder to clar driven by\nPatrick Steinhardt. Test functions are structured as a standalone to\ntest individual hash string and literal case.\n\nMentored-by: Patrick Steinhardt <ps@pks.im>\nSigned-off-by: Seyi Kuforiji <kuforiji98@gmail.com>\n---\nChanges relative to v2:\n\n  - A couple of fixes to code formatting to match our standards \n\nThanks\nSeyi\n---\nRange-diff against v2:\n-:  ---------- > 1:  fcc2a376a5 t/unit-tests: convert hash to use clar test framework\n\n Makefile                            |  2 +-\n t/meson.build                       |  2 +-\n t/unit-tests/{t-hash.c => u-hash.c} | 71 +++++++++++++++++++----------\n 3 files changed, 50 insertions(+), 25 deletions(-)\n rename t/unit-tests/{t-hash.c => u-hash.c} (80%)\n\ndiff --git a/Makefile b/Makefile\nindex 97e8385b66..d3011e30f7 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -1338,6 +1338,7 @@ THIRD_PARTY_SOURCES += $(UNIT_TEST_DIR)/clar/%\n THIRD_PARTY_SOURCES += $(UNIT_TEST_DIR)/clar/clar/%\n \n CLAR_TEST_SUITES += u-ctype\n+CLAR_TEST_SUITES += u-hash\n CLAR_TEST_SUITES += u-strvec\n CLAR_TEST_PROG = $(UNIT_TEST_BIN)/unit-tests$(X)\n CLAR_TEST_OBJS = $(patsubst %,$(UNIT_TEST_DIR)/%.o,$(CLAR_TEST_SUITES))\n@@ -1345,7 +1346,6 @@ CLAR_TEST_OBJS += $(UNIT_TEST_DIR)/clar/clar.o\n CLAR_TEST_OBJS += $(UNIT_TEST_DIR)/unit-test.o\n \n UNIT_TEST_PROGRAMS += t-example-decorate\n-UNIT_TEST_PROGRAMS += t-hash\n UNIT_TEST_PROGRAMS += t-hashmap\n UNIT_TEST_PROGRAMS += t-mem-pool\n UNIT_TEST_PROGRAMS += t-oid-array\ndiff --git a/t/meson.build b/t/meson.build\nindex 602ebfe6a2..7b35eadbc8 100644\n--- a/t/meson.build\n+++ b/t/meson.build\n@@ -1,5 +1,6 @@\n clar_test_suites = [\n   'unit-tests/u-ctype.c',\n+  'unit-tests/u-hash.c',\n   'unit-tests/u-strvec.c',\n ]\n \n@@ -41,7 +42,6 @@ test('unit-tests', clar_unit_tests)\n \n unit_test_programs = [\n   'unit-tests/t-example-decorate.c',\n-  'unit-tests/t-hash.c',\n   'unit-tests/t-hashmap.c',\n   'unit-tests/t-mem-pool.c',\n   'unit-tests/t-oid-array.c',\ndiff --git a/t/unit-tests/t-hash.c b/t/unit-tests/u-hash.c\nsimilarity index 80%\nrename from t/unit-tests/t-hash.c\nrename to t/unit-tests/u-hash.c\nindex e62647019b..a0320efe4b 100644\n--- a/t/unit-tests/t-hash.c\n+++ b/t/unit-tests/u-hash.c\n@@ -1,14 +1,11 @@\n-#include \"test-lib.h\"\n+#include \"unit-test.h\"\n #include \"hex.h\"\n #include \"strbuf.h\"\n \n static void check_hash_data(const void *data, size_t data_length,\n \t\t\t    const char *expected_hashes[])\n {\n-\tif (!check(data != NULL)) {\n-\t\ttest_msg(\"BUG: NULL data pointer provided\");\n-\t\treturn;\n-\t}\n+\tcl_assert(data != NULL);\n \n \tfor (size_t i = 1; i < ARRAY_SIZE(hash_algos); i++) {\n \t\tgit_hash_ctx ctx;\n@@ -19,66 +16,94 @@ static void check_hash_data(const void *data, size_t data_length,\n \t\talgop->update_fn(&ctx, data, data_length);\n \t\talgop->final_fn(hash, &ctx);\n \n-\t\tif (!check_str(hash_to_hex_algop(hash, algop), expected_hashes[i - 1]))\n-\t\t\ttest_msg(\"result does not match with the expected for %s\\n\", hash_algos[i].name);\n+\t\tcl_assert_equal_s(hash_to_hex_algop(hash,algop), expected_hashes[i - 1]);\n \t}\n }\n \n /* Works with a NUL terminated string. Doesn't work if it should contain a NUL character. */\n #define TEST_HASH_STR(data, expected_sha1, expected_sha256) do { \\\n \t\tconst char *expected_hashes[] = { expected_sha1, expected_sha256 }; \\\n-\t\tTEST(check_hash_data(data, strlen(data), expected_hashes), \\\n-\t\t     \"SHA1 and SHA256 (%s) works\", #data); \\\n+\t\tcheck_hash_data(data, strlen(data), expected_hashes); \\\n \t} while (0)\n \n /* Only works with a literal string, useful when it contains a NUL character. */\n #define TEST_HASH_LITERAL(literal, expected_sha1, expected_sha256) do { \\\n \t\tconst char *expected_hashes[] = { expected_sha1, expected_sha256 }; \\\n-\t\tTEST(check_hash_data(literal, (sizeof(literal) - 1), expected_hashes), \\\n-\t\t     \"SHA1 and SHA256 (%s) works\", #literal); \\\n+\t\tcheck_hash_data(literal, (sizeof(literal) - 1), expected_hashes); \\\n \t} while (0)\n \n-int cmd_main(int argc UNUSED, const char **argv UNUSED)\n+void test_hash__empty_string(void)\n {\n-\tstruct strbuf aaaaaaaaaa_100000 = STRBUF_INIT;\n-\tstruct strbuf alphabet_100000 = STRBUF_INIT;\n-\n-\tstrbuf_addstrings(&aaaaaaaaaa_100000, \"aaaaaaaaaa\", 100000);\n-\tstrbuf_addstrings(&alphabet_100000, \"abcdefghijklmnopqrstuvwxyz\", 100000);\n-\n \tTEST_HASH_STR(\"\",\n \t\t\"da39a3ee5e6b4b0d3255bfef95601890afd80709\",\n \t\t\"e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855\");\n+}\n+\n+void test_hash__single_character(void)\n+{\n \tTEST_HASH_STR(\"a\",\n \t\t\"86f7e437faa5a7fce15d1ddcb9eaeaea377667b8\",\n \t\t\"ca978112ca1bbdcafac231b39a23dc4da786eff8147c4e72b9807785afee48bb\");\n+}\n+\n+void test_hash__multi_character(void)\n+{\n \tTEST_HASH_STR(\"abc\",\n \t\t\"a9993e364706816aba3e25717850c26c9cd0d89d\",\n \t\t\"ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad\");\n+}\n+\n+void test_hash__message_digest(void)\n+{\n \tTEST_HASH_STR(\"message digest\",\n \t\t\"c12252ceda8be8994d5fa0290a47231c1d16aae3\",\n \t\t\"f7846f55cf23e14eebeab5b4e1550cad5b509e3348fbc4efa3a1413d393cb650\");\n+}\n+\n+void test_hash__alphabet(void)\n+{\n \tTEST_HASH_STR(\"abcdefghijklmnopqrstuvwxyz\",\n \t\t\"32d10c7b8cf96570ca04ce37f2a19d84240d3a89\",\n \t\t\"71c480df93d6ae2f1efad1447c66c9525e316218cf51fc8d9ed832f2daf18b73\");\n+}\n+\n+void test_hash__aaaaaaaaaa_100000(void)\n+{\n+\tstruct strbuf aaaaaaaaaa_100000 = STRBUF_INIT;\n+\tstrbuf_addstrings(&aaaaaaaaaa_100000, \"aaaaaaaaaa\", 100000);\n \tTEST_HASH_STR(aaaaaaaaaa_100000.buf,\n \t\t\"34aa973cd4c4daa4f61eeb2bdbad27316534016f\",\n \t\t\"cdc76e5c9914fb9281a1c7e284d73e67f1809a48a497200e046d39ccc7112cd0\");\n+\tstrbuf_release(&aaaaaaaaaa_100000);\n+}\n+\n+void test_hash__alphabet_100000(void)\n+{\n+\tstruct strbuf alphabet_100000 = STRBUF_INIT;\n+\tstrbuf_addstrings(&alphabet_100000, \"abcdefghijklmnopqrstuvwxyz\", 100000);\n \tTEST_HASH_STR(alphabet_100000.buf,\n \t\t\"e7da7c55b3484fdf52aebec9cbe7b85a98f02fd4\",\n \t\t\"e406ba321ca712ad35a698bf0af8d61fc4dc40eca6bdcea4697962724ccbde35\");\n+\tstrbuf_release(&alphabet_100000);\n+}\n+\n+void test_hash__zero_blob_literal(void)\n+{\n \tTEST_HASH_LITERAL(\"blob 0\\0\",\n \t\t\"e69de29bb2d1d6434b8b29ae775ad8c2e48c5391\",\n \t\t\"473a0f4c3be8a93681a267e3b1e9a7dcda1185436fe141f7749120a303721813\");\n+}\n+\n+void test_hash__three_blob_literal(void)\n+{\n \tTEST_HASH_LITERAL(\"blob 3\\0abc\",\n \t\t\"f2ba8f84ab5c1bce84a7b441cb1959cfc7093b7f\",\n \t\t\"c1cf6e465077930e88dc5136641d402f72a229ddd996f627d60e9639eaba35a6\");\n+}\n+\n+void test_hash__zero_tree_literal(void)\n+{\n \tTEST_HASH_LITERAL(\"tree 0\\0\",\n \t\t\"4b825dc642cb6eb9a060e54bf8d69288fbee4904\",\n \t\t\"6ef19b41225c5369f1c104d45d8d85efa9b057b53b14b4b9b939dd74decc5321\");\n-\n-\tstrbuf_release(&aaaaaaaaaa_100000);\n-\tstrbuf_release(&alphabet_100000);\n-\n-\treturn test_done();\n }\n-- \n2.34.1\n\n"},{"id":"510257","messageId":"Z3_m5uNhXjdFyGJK@pks.im","threadId":"62755","inReplyTo":"20250109140952.5267-1-kuforiji98@gmail.com","subject":"Re: [PATCH v3] t/unit-tests: convert hash to use clar test framework","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-01-09T15:10:37Z","receivedAt":"2025-01-09T15:10:44Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Thu, Jan 09, 2025 at 03:09:52PM +0100, Seyi Kuforiji wrote:\n> Range-diff against v2:\n> -:  ---------- > 1:  fcc2a376a5 t/unit-tests: convert hash to use clar test framework\n\nHm. The range-diff is a bit funny -- I would have expected it to\nrecognize that it's the same patch as not a lot of things have changed\ncompared to v2. Did you maybe compare to v1 by accident?\n\nAnyway, this is of course no reason to send a revised version. The\nchanges themselves look good to me, thanks!\n\nPartick\n"},{"id":"510260","messageId":"xmqqmsg0j762.fsf@gitster.g","threadId":"62755","inReplyTo":"20250109140952.5267-1-kuforiji98@gmail.com","subject":"Re: [PATCH v3] t/unit-tests: convert hash to use clar test framework","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-01-09T16:14:45Z","receivedAt":"2025-01-09T16:14:47Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Seyi Kuforiji <kuforiji98@gmail.com> writes:\n\n> Adapt the hash test functions to clar framework by using clar\n> assertions where necessary. Following the consensus to convert\n> the unit-tests scripts found in the t/unit-tests folder to clar driven by\n> Patrick Steinhardt. Test functions are structured as a standalone to\n> test individual hash string and literal case.\n>\n> Mentored-by: Patrick Steinhardt <ps@pks.im>\n> Signed-off-by: Seyi Kuforiji <kuforiji98@gmail.com>\n\nThe change to the test program was a very pleasant read.  It was\ntrivially obvious that the new version faithfully rewrites the\noriginal.  E.g., ...\n\n>  static void check_hash_data(const void *data, size_t data_length,\n>  \t\t\t    const char *expected_hashes[])\n>  {\n> -\tif (!check(data != NULL)) {\n> -\t\ttest_msg(\"BUG: NULL data pointer provided\");\n> -\t\treturn;\n> -\t}\n> +\tcl_assert(data != NULL);\n\n... instead of using check() and giving message with test_msg(), the\nclar framework gives cl_assert() for us to use.\n\nAnd ...\n\n>  #define TEST_HASH_STR(data, expected_sha1, expected_sha256) do { \\\n>  \t\tconst char *expected_hashes[] = { expected_sha1, expected_sha256 }; \\\n> -\t\tTEST(check_hash_data(data, strlen(data), expected_hashes), \\\n> -\t\t     \"SHA1 and SHA256 (%s) works\", #data); \\\n> +\t\tcheck_hash_data(data, strlen(data), expected_hashes); \\\n\n... instead of TEST() macro with the title string, we call the\nunderlying test function.  The loss of the message does not hurt us,\nas both the test suite name and name of each test are shown by the\nclar framework.\n\n> -int cmd_main(int argc UNUSED, const char **argv UNUSED)\n> +void test_hash__empty_string(void)\n>  {\n> -\tstruct strbuf aaaaaaaaaa_100000 = STRBUF_INIT;\n> -\tstruct strbuf alphabet_100000 = STRBUF_INIT;\n> -\n> -\tstrbuf_addstrings(&aaaaaaaaaa_100000, \"aaaaaaaaaa\", 100000);\n> -\tstrbuf_addstrings(&alphabet_100000, \"abcdefghijklmnopqrstuvwxyz\", 100000);\n> -\n>  \tTEST_HASH_STR(\"\",\n>  \t\t\"da39a3ee5e6b4b0d3255bfef95601890afd80709\",\n>  \t\t\"e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855\");\n> +}\n\nAnd the fact that the body of each test function are unchanged from\nthe original helps to build confidence in the faithfulness of the\nconversion.\n\nThe strbuf allocation is lost from here, and clean-up is lost from\nthe end of the file, and they are done in the function that needs\nthe strbuf, which also contributes to the clarity of the new\nversion.\n\nNicely done.  Will queue.\n\nThanks.\n"}]}