{"thread":{"id":"61158","subject":"[GSoC][RFC][Proposal] Move existing tests to a unit testing framework","startedAt":"2024-03-19T22:55:38Z","lastAt":"2024-03-26T09:33:01Z","messageCount":4,"participants":["Ghanshyam Thakkar","Christian Couder"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"490975","messageId":"20240319225444.21574-1-shyamthakkar001@gmail.com","threadId":"61158","inReplyTo":null,"subject":"[GSoC][RFC][Proposal] Move existing tests to a unit testing framework","fromName":"Ghanshyam Thakkar","fromEmail":"shyamthakkar001@gmail.com","sentAt":"2024-03-19T22:54:26Z","receivedAt":"2024-03-19T22:55:38Z","isPatch":false,"sender":{"key":"shyamthakkar001@gmail.com","avatar":"https://avatars.githubusercontent.com/u/72698233?v=4"},"body":"Hello everyone,\n\nThis is my proposal for the project \"Move existing tests to a unit testing\nframework\" in Google Summer of Code 2024. The web version can be viewed at:\nhttps://docs.google.com/document/d/1wmosedy-UKd_mhAAjccv1qETO1q00s-npYj2m6g-Hd0/edit?usp=sharing\n\nI appreciate any feedback on this proposal.\n\nThanks.\n\n-- >8 --\nMove existing tests to a unit testing framework\n\nPersonal Information\n--------------------\n\nName: Ghanshyam Thakkar\nE-mail: shyamthakkar001@gmail.com\nPh. No.: +91 7990974044\n\nEducation: L.D. College of Engineering, Gujarat, India\nYear: IV\nDegree: Bachelors in Electronics and\n Communications Engineering\n\nGitHub: https://github.com/spectre10\nTime-zone: UTC +5:30 (IST)\n\n\nOverview\n--------\n\nInitially Git used to only rely on shell scripts to test the functionality\nusually deemed to be internal (e.g. libraries, functions etc.) This was achieved\nthrough t/helper binaries which would take input via stdin and output through\nstdout and the test scripts would consume those outputs. This translation is\ncostly due to the following reasons:\n\n- Each test script creates a new git repository which is many times not needed.\n See here[1] for example.\n- These scripts spawn processes every time they need a certain output. And \n spawning processes are expensive (especially on windows).\n- Difficult setups: sometimes the functions or the libraries we are testing need\n some special setup such as defining flags for custom behavior etc. which\n cannot be done through the shell scripts, hence we might forego testing those\n conditions.\n\nMoving to the unit testing framework would give us many benefits such as\nincreased runtime performance, and therefore lower test duration and solves all\nof the above points. The choice of framework and the rationale behind it is\nthoroughly described in Documentation/technical/unit-tests.txt. Therefore, the\ngoal of this project is to move existing unit tests from t/helper/* and its\ncorresponding scripts to the new unit testing framework. And there has been work\ngoing on to do this by Outreachy intern Achu Luma.\n\nThe expected project difficulty is medium and the expected project size would be\n350 hours.\n\n\nPre-GSoC\n--------\nI initially got into Git’s codebase in December, 2023 and started my\ncontribution journey in January, 2024. I worked on mostly what I found\ninteresting and within my reach. Following is the list of contributions that I\nhave made, in chronological order:\n\n- [PATCH v6 0/2] t7501: add tests for --include, --only, --signoff\n Status: merged into master\n Merge Commit: 2be9ccf23e0592b83b78e719574e580e79db0375\n Description:\n This patch series added missing tests for --include, --only and --signoff\n options of git-commit. While working on this patch I accidentally reproduced\n a bug where in an untracked path provided to the commit command with -i\n would not error out. This was noticed by Junio. Therefore, this patch also\n included a TODO comment describing this bug.\n Mailing list thread:\n https://lore.kernel.org/git/20240109060417.1144647-2-shyamthakkar001@gmail.com\n\n- [PATCH v3 1/2] t0024: avoid losing exit status to pipes\n Status: merged into master\n Merge Commit: 40225ba8b494080d7f90dd5e129daa7b11c613d1\n Description:\n Although this was not my first contribution, it was done to fulfill the\n microproject criteria from the list of micro-projects on Git Developer\n Pages. The first patch replaces the pipe to the redirection operator to\n store the output to a temporary file to avoid losing exit status of the git\n commands. And the second patch of the series fixes the style violations to\n adhere to the current standard described in CodingGuidelines.\n Mailing list thread:\n https://lore.kernel.org/git/20240118215407.8609-1-shyamthakkar001@gmail.com/\n\n- [PATCH v6 0/2] add-patch: classify '@' as a synonym for 'HEAD'\n Status: merged into master\n Merge Commit: 65462776c2963b377968e580ace1590238bf79c1\n Description:\n The first patch of this series removed the disparity of command line output\n of using ‘HEAD’ vs ‘@’ in ‘git reset/restore/checkout -p’. And the second\n patch removed the perl prerequisites in the test scripts which use the patch\n mode functionality.\n Mailing list thread:\n https://lore.kernel.org/git/20240128181202.986753-2-shyamthakkar001@gmail.com/\n\n- [PATCH] restore: allow --staged on unborn branch\n Status: Discontinued\n Description:\n This patch added functionality to assume an empty tree when on an unborn\n branch to be able to use ‘restore –staged’. However, this was discontinued\n due to lack of community interest. In hindsight, I think that this would\n have been an acceptable patch, had I described it well.\n Mailing list thread:\n https://lore.kernel.org/git/20240206230357.1097505-2-shyamthakkar001@gmail.com/\n\n- [PATCH] unit-tests: convert t/helper/test-oid-array.c to unit-tests\n Status: on hold until GSoC\n Description:\n This was used as a practice patch to the current project proposal. This will\n be used as a reference in the proposal ahead.\n Mailing list thread:\n https://lore.kernel.org/git/20240223193257.9222-1-shyamthakkar001@gmail.com/\n \n- [PATCH v2] setup: remove unnecessary variable\n Status: Merged to master\n Merge Commit: 272fd9125aae215ece1c465a4b7d336cf81c3e62\n Description:\n I initially proposed the TODO comment removed through this patch as a\n micro-project for my first patch. However, the TODO comment was a result of\n misunderstanding, therefore this patch did some minor code simplifications\n along with the removal of the TODO comment.\n Mailing list thread:\n https://lore.kernel.org/git/20240304151811.511780-1-shyamthakkar001@gmail.com/\n\n- [PATCH 0/2] commit, add: error out when passing untracked path \n Status: WIP\n Description:\n This patch series would fix the potential bug discovered in the first patch\n that I sent (--include tests).\n\tMailing list thread:\n https://lore.kernel.org/git/20240318155219.494206-2-shyamthakkar001@gmail.com/\n\n- Helped a fellow contributor by reviewing their patches\n Thread links:\n - https://lore.kernel.org/git/CZG3HO25QLAG.3Q9V03SCO99HL@gmail.com/\n - https://lore.kernel.org/git/CZHJPF604DV9.X0A0VX1AB7P8@gmail.com/\n\nProposed Project\n----------------\n\n----What’s unit testing----\n\nUnit testing is a method to test a specific unit of source code (i.e. a\nfunction, a module etc.). This is very helpful in catching all of the corner\ncases and possible scenarios.\n\n----Steps to convert the existing unit tests to the new framework----\n\nIt can be thought of as a series of steps which are outlined below:\n- Identify a suitable candidate from t/helper directory.\n- Each t/helper unit test has a corresponding shell script which actually tests\n the output from the binary. Each test-case in that script would ideally become\n a separate function (and therefore a single test-case) in the migrated unit\n test.\n- Convert the test logic from the shell script to C. This would involve\n understanding the underlying library/functionality which is being\n tested. Subsequently, make functions which would be ideally be a single\n testcase.\n- These functions can be called via the TEST() macro in the cmd_main\n function which is the entry point to the test.\n- Each of these functions contains a set of {check(), check_int() etc.} macro\n functions which check the condition provided to them and if it fails, prints\n a message to the stdout. If even a single check fails the whole test-case is\n considered a failure.\n- Modify Makefile to add the reference of the new test to the UNIT_TEST_PROGRAMS\n variable.\n- The skeleton of the new unit test would look something like this:\n\n #include \"test-lib.h\"\n\n static void testcase_1()\n {\n\t ...\n\t check(actual == expected);\n\t ...\n }\n\n int cmd_main(int argc, const char **argv)\n {\n\t TEST(testcase_1(), \"test description\");\n\t return test_done();\n }\n\n- After the migration remove the references of t/helper/{old-test-helper}.{c, o}\n from the Makefile and from the t/helper/test-tool.{c, h}. And subsequently\n remove the shell script which used to consume the old helper binary.\n\n----Additional Notes along with a Reference Implementation----\n\nThese tests usually contain duplicate logic with variations in input and output.\nIn such cases, we can define macro functions to not duplicate such logic. I.e.\nin t-ctype, we can see how a custom macro is defined to avoid duplication of\ntest logic, with variation only in the input being used. Also, some these\nexisting tests are not worth migrating. For example, test-tool binaries which\nare also used outside of the corresponding shell script (i.e. used in other\ntests for setup purposes) would be low on the priority list of possible\nmigrations.\n\nI have made a reference implementation of t-oid-array.c which migrates\nt/helper/test-oid-array.c and t/0064-oid-array.sh to the new framework, which\ncan be viewed here[2]. Note that the failing tests are not related to my\nimplementation and rather a known issue[3]. It may or may not to be good enough to\nbe merged into master, however it sufficiently showcases my abilities to\nunderstand framework, the use of different macros and the ability to understand\ndifferent internal libraries and data-structures such oidarray itself.\n\nThis implementation was also reviewed by Christian Couder on the mailing list\nand I have made some adjustments according to the feedback.\n\nThis implementation uses a macro to test the ordered enumeration of oidarray\nwith different inputs. And also tests the lookup capabilities of oidarray with\ndifferent queries and inputs with the help of a macro. There are also various\nhelper functions defined to help with printing debug output, generating\nhexadecimal representations, etc.\n\n----Previous Work----\n\nTAP implementation along with t-basic and t-strbuf:\nhttps://github.com/git/git/commit/e137fe3b\n\nt-mempool: https://github.com/git/git/commit/6cbae640\nt-ctype: https://github.com/git/git/commit/e875d451\nt-prio-queue: https://github.com/git/git/commit/808b77e5\n\nAchu Luma has been doing this migration as part of Outreachy internship. Their\nbranches can be seen here[4].\n\n----Goal----\n\nThe end goal of this project would be to migrate as many unit tests as possible\naccording to the steps outlined above. In doing so, also enhance some of the\ntests as needed to be extensible such as the ability to test different hash\nalgorithms on a single oidarray. This enhancement is not yet implemented in the\nreference implementation due to the series which enables the use of different\nhash algorithms on oidarray not yet merged into master (in next though).\n\nCurrently, there are 78 test-*.c files (not including test-tool.c) in t/helper/\ndirectory according to the master branch. Of course, migrating all of them would\nbe a difficult task in 350 hours, therefore I plan to migrate around 1 unit test\nper week during the Community Bonding and Coding Phase. This may fluctuate\ndepending on the type of test. Some of those tests are already being worked on\nby Achu Luma.\n\n----Timeline----\n\nPre-GSoC\n(Until May 1)\n- Continue to work on different things like solving the bug discovered in the\n first patch series that I sent. Be engaged in the community.\n\nCommunity Bonding\n(May 1 - May 26)\n- Talk with mentors and identify the tests which are suitable for migration.\n Learn the libraries which are used for those tests and read up on the API.\n Look at Achu Luma’s branches to further familiarize myself with the migration\n process. Start the migration early with the mentors’ permission.\n \nPhase I\n(May 27 - July 11)\n- Continue implementing the tests in the unit testing framework with the\n guidance of mentors and send out patches to the mailing list for community\n approval. Approximately 6-7 tests would be done/cooking for migration at\n the end of this Phase.\n\nPhase II\n(July 12 - Aug 18)\n- Continue the migration and talk with the mentors about the pace, quality of\n patches and seek feedback. And enjoy the process. Another 5-6 tests would be\n done/cooking at the end of this Phase.\n \nFinal Week\n(Aug 19 - Aug 26)\n- Finish up any remaining tests.\n- Fix any bugs and some final touches.\n- Make a final report about the work accomplished and outline future work.\n\n----Blogging----\n\nI believe that writing about one’s work helps them track their progress from a\nbird’s eye view. And also helps them realize if they are making mistakes from a\nlong term perspective. I plan to blog about the progress bi-weekly. Although I\nhave not setup the blog yet, it will be at:\n https://spectre10.github.io\n \n----Availability----\n\nMy current semester ends on 30th April and my exam/viva is tentatively on 7th\nMay. After that I have freed my summer for GSoC, therefore I will be able to\ngive a minimum of 35-40 hours per week.\n\nPost-GSoC\n---------\n\nThe Git Community has helped me very much and tolerated my beginner mistakes.\nI have grown as a developer since I started contributing to Git. I learned the\nimportance of writing good commit messages, benefits of splitting up patches,\neffective programming style and good communication etiquettes. Therefore, I plan\nto be involved even after my GSoC journey ends. I am very much involved in the\nGit ecosystem and also contribute to another project in the Git ecosystem called\ngittuf[5]. Also post-gsoc, I am planning to help out in aggregating for Git Rev\nNews, which I personally enjoy reading.\n\nMy Appreciation\n---------------\n\nI would like extend my thanks to all of the folks on the mailing list and\nDiscord who have helped me in contributing to the Git Project including Junio,\nChristian Couder, Phillip Wood, Elijah Newren and many others. And I have also\ntaken some references of Achu Luma’s work for this proposal, so thanks to\nher, too.\n\nThanks & Regards,\nGhanshyam\n\nReferences:\n[1], [2]: https://github.com/spectre10/git/commit/9bfbb22ced3c4d15a215a84aa40043a30dc1bac0\n[3]: https://lore.kernel.org/git/20240318090848.GC602575@coredump.intra.peff.net/T/#mc32405849ac4265ad36670480709d744f1d9e495\n[4]: https://github.com/achluma/git/branches\n[5]: https://github.com/gittuf/gittuf\n\n"},{"id":"491011","messageId":"CAP8UFD2COoXfDdS1eg5DR_0NL8bOhCHvXUkqkfzLbSejRmgwSw@mail.gmail.com","threadId":"61158","inReplyTo":"20240319225444.21574-1-shyamthakkar001@gmail.com","subject":"Re: [GSoC][RFC][Proposal] Move existing tests to a unit testing framework","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2024-03-20T13:58:19Z","receivedAt":"2024-03-20T13:58:33Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Hi,\n\nOn Tue, Mar 19, 2024 at 11:55 PM Ghanshyam Thakkar\n wrote:\n>\n> Hello everyone,\n>\n> This is my proposal for the project \"Move existing tests to a unit testing\n> framework\" in Google Summer of Code 2024. The web version can be viewed at:\n> https://docs.google.com/document/d/1wmosedy-UKd_mhAAjccv1qETO1q00s-npYj2m6g-Hd0/edit?usp=sharing\n>\n> I appreciate any feedback on this proposal.\n>\n> Thanks.\n>\n> -- >8 --\n> Move existing tests to a unit testing framework\n>\n> Personal Information\n> --------------------\n>\n> Name: Ghanshyam Thakkar\n> E-mail: shyamthakkar001@gmail.com\n> Ph. No.: +91 7990974044\n>\n> Education: L.D. College of Engineering, Gujarat, India\n> Year: IV\n\nIs it year 4 out of 4 or 5 or more? Sorry, but it's interesting to\nknow when you are going to graduate and if you might need to look for\na full time job soon.\n\n> Degree: Bachelors in Electronics and\n> Communications Engineering\n>\n> GitHub: https://github.com/spectre10\n> Time-zone: UTC +5:30 (IST)\n>\n>\n> Overview\n> --------\n>\n> Initially Git used to only rely on shell scripts to test the functionality\n> usually deemed to be internal (e.g. libraries, functions etc.) This was achieved\n> through t/helper binaries which would take input via stdin and output through\n> stdout and the test scripts would consume those outputs.\n\nI think some test-tool helpers also take arguments on the command line.\n\n> This translation is\n> costly due to the following reasons:\n>\n> - Each test script creates a new git repository which is many times not needed.\n> See here[1] for example.\n> - These scripts spawn processes every time they need a certain output. And\n> spawning processes are expensive (especially on windows).\n> - Difficult setups: sometimes the functions or the libraries we are testing need\n> some special setup such as defining flags for custom behavior etc. which\n> cannot be done through the shell scripts, hence we might forego testing those\n> conditions.\n>\n> Moving to the unit testing framework would give us many benefits such as\n> increased runtime performance, and therefore lower test duration and solves all\n> of the above points. The choice of framework and the rationale behind it is\n> thoroughly described in Documentation/technical/unit-tests.txt. Therefore, the\n> goal of this project is to move existing unit tests from t/helper/* and its\n> corresponding scripts to the new unit testing framework. And there has been work\n> going on to do this by Outreachy intern Achu Luma.\n>\n> The expected project difficulty is medium and the expected project size would be\n> 350 hours.\n>\n>\n> Pre-GSoC\n> --------\n> I initially got into Git’s codebase in December, 2023 and started my\n> contribution journey in January, 2024. I worked on mostly what I found\n> interesting and within my reach. Following is the list of contributions that I\n> have made, in chronological order:\n>\n> - [PATCH v6 0/2] t7501: add tests for --include, --only, --signoff\n> Status: merged into master\n> Merge Commit: 2be9ccf23e0592b83b78e719574e580e79db0375\n> Description:\n> This patch series added missing tests for --include, --only and --signoff\n> options of git-commit. While working on this patch I accidentally reproduced\n> a bug where in an untracked path provided to the commit command with -i\n> would not error out. This was noticed by Junio. Therefore, this patch also\n> included a TODO comment describing this bug.\n> Mailing list thread:\n> https://lore.kernel.org/git/20240109060417.1144647-2-shyamthakkar001@gmail.com\n>\n> - [PATCH v3 1/2] t0024: avoid losing exit status to pipes\n> Status: merged into master\n> Merge Commit: 40225ba8b494080d7f90dd5e129daa7b11c613d1\n> Description:\n> Although this was not my first contribution, it was done to fulfill the\n> microproject criteria from the list of micro-projects on Git Developer\n> Pages. The first patch replaces the pipe to the redirection operator to\n> store the output to a temporary file to avoid losing exit status of the git\n> commands. And the second patch of the series fixes the style violations to\n> adhere to the current standard described in CodingGuidelines.\n> Mailing list thread:\n> https://lore.kernel.org/git/20240118215407.8609-1-shyamthakkar001@gmail.com/\n>\n> - [PATCH v6 0/2] add-patch: classify '@' as a synonym for 'HEAD'\n> Status: merged into master\n> Merge Commit: 65462776c2963b377968e580ace1590238bf79c1\n> Description:\n> The first patch of this series removed the disparity of command line output\n> of using ‘HEAD’ vs ‘@’ in ‘git reset/restore/checkout -p’. And the second\n> patch removed the perl prerequisites in the test scripts which use the patch\n> mode functionality.\n> Mailing list thread:\n> https://lore.kernel.org/git/20240128181202.986753-2-shyamthakkar001@gmail.com/\n>\n> - [PATCH] restore: allow --staged on unborn branch\n> Status: Discontinued\n> Description:\n> This patch added functionality to assume an empty tree when on an unborn\n> branch to be able to use ‘restore –staged’. However, this was discontinued\n> due to lack of community interest. In hindsight, I think that this would\n> have been an acceptable patch, had I described it well.\n> Mailing list thread:\n> https://lore.kernel.org/git/20240206230357.1097505-2-shyamthakkar001@gmail.com/\n\nI think it's still Ok to send a V2 with improved explanations. Perhaps\nyou can do it after improving this proposal though.\n\n> - [PATCH] unit-tests: convert t/helper/test-oid-array.c to unit-tests\n> Status: on hold until GSoC\n> Description:\n> This was used as a practice patch to the current project proposal. This will\n> be used as a reference in the proposal ahead.\n> Mailing list thread:\n> https://lore.kernel.org/git/20240223193257.9222-1-shyamthakkar001@gmail.com/\n>\n> - [PATCH v2] setup: remove unnecessary variable\n> Status: Merged to master\n> Merge Commit: 272fd9125aae215ece1c465a4b7d336cf81c3e62\n> Description:\n> I initially proposed the TODO comment removed through this patch as a\n> micro-project for my first patch. However, the TODO comment was a result of\n> misunderstanding, therefore this patch did some minor code simplifications\n> along with the removal of the TODO comment.\n> Mailing list thread:\n> https://lore.kernel.org/git/20240304151811.511780-1-shyamthakkar001@gmail.com/\n>\n> - [PATCH 0/2] commit, add: error out when passing untracked path\n> Status: WIP\n> Description:\n> This patch series would fix the potential bug discovered in the first patch\n> that I sent (--include tests).\n> Mailing list thread:\n> https://lore.kernel.org/git/20240318155219.494206-2-shyamthakkar001@gmail.com/\n>\n> - Helped a fellow contributor by reviewing their patches\n> Thread links:\n> - https://lore.kernel.org/git/CZG3HO25QLAG.3Q9V03SCO99HL@gmail.com/\n> - https://lore.kernel.org/git/CZHJPF604DV9.X0A0VX1AB7P8@gmail.com/\n>\n> Proposed Project\n> ----------------\n>\n> ----What’s unit testing----\n>\n> Unit testing is a method to test a specific unit of source code (i.e. a\n> function, a module etc.). This is very helpful in catching all of the corner\n> cases and possible scenarios.\n>\n> ----Steps to convert the existing unit tests to the new framework----\n>\n> It can be thought of as a series of steps which are outlined below:\n> - Identify a suitable candidate from t/helper directory.\n> - Each t/helper unit test has a corresponding shell script which actually tests\n> the output from the binary. Each test-case in that script would ideally become\n> a separate function (and therefore a single test-case) in the migrated unit\n> test.\n> - Convert the test logic from the shell script to C. This would involve\n> understanding the underlying library/functionality which is being\n> tested. Subsequently, make functions which would be ideally be a single\n> testcase.\n> - These functions can be called via the TEST() macro in the cmd_main\n> function which is the entry point to the test.\n> - Each of these functions contains a set of {check(), check_int() etc.} macro\n> functions which check the condition provided to them and if it fails, prints\n> a message to the stdout. If even a single check fails the whole test-case is\n> considered a failure.\n> - Modify Makefile to add the reference of the new test to the UNIT_TEST_PROGRAMS\n> variable.\n> - The skeleton of the new unit test would look something like this:\n>\n> #include \"test-lib.h\"\n>\n> static void testcase_1()\n> {\n> ...\n> check(actual == expected);\n> ...\n> }\n>\n> int cmd_main(int argc, const char **argv)\n> {\n> TEST(testcase_1(), \"test description\");\n> return test_done();\n> }\n>\n> - After the migration remove the references of t/helper/{old-test-helper}.{c, o}\n> from the Makefile and from the t/helper/test-tool.{c, h}. And subsequently\n> remove the shell script which used to consume the old helper binary.\n>\n> ----Additional Notes along with a Reference Implementation----\n>\n> These tests usually contain duplicate logic with variations in input and output.\n> In such cases, we can define macro functions to not duplicate such logic. I.e.\n> in t-ctype, we can see how a custom macro is defined to avoid duplication of\n> test logic, with variation only in the input being used. Also, some these\n\ns/some these/some of these/\n\n> existing tests are not worth migrating. For example, test-tool binaries which\n> are also used outside of the corresponding shell script (i.e. used in other\n> tests for setup purposes) would be low on the priority list of possible\n> migrations.\n>\n> I have made a reference implementation of t-oid-array.c which migrates\n> t/helper/test-oid-array.c and t/0064-oid-array.sh to the new framework, which\n> can be viewed here[2]. Note that the failing tests are not related to my\n> implementation and rather a known issue[3]. It may or may not to be good enough to\n> be merged into master, however it sufficiently showcases my abilities to\n> understand framework, the use of different macros and the ability to understand\n> different internal libraries and data-structures such oidarray itself.\n>\n> This implementation was also reviewed by Christian Couder on the mailing list\n> and I have made some adjustments according to the feedback.\n>\n> This implementation uses a macro to test the ordered enumeration of oidarray\n> with different inputs. And also tests the lookup capabilities of oidarray with\n> different queries and inputs with the help of a macro. There are also various\n> helper functions defined to help with printing debug output, generating\n> hexadecimal representations, etc.\n>\n> ----Previous Work----\n>\n> TAP implementation along with t-basic and t-strbuf:\n> https://github.com/git/git/commit/e137fe3b\n>\n> t-mempool: https://github.com/git/git/commit/6cbae640\n> t-ctype: https://github.com/git/git/commit/e875d451\n> t-prio-queue: https://github.com/git/git/commit/808b77e5\n>\n> Achu Luma has been doing this migration as part of Outreachy internship. Their\n> branches can be seen here[4].\n>\n> ----Goal----\n>\n> The end goal of this project would be to migrate as many unit tests as possible\n> according to the steps outlined above. In doing so, also enhance some of the\n> tests as needed to be extensible such as the ability to test different hash\n> algorithms on a single oidarray. This enhancement is not yet implemented in the\n> reference implementation due to the series which enables the use of different\n> hash algorithms on oidarray not yet merged into master (in next though).\n>\n> Currently, there are 78 test-*.c files (not including test-tool.c) in t/helper/\n> directory according to the master branch. Of course, migrating all of them would\n> be a difficult task in 350 hours, therefore I plan to migrate around 1 unit test\n> per week during the Community Bonding and Coding Phase. This may fluctuate\n> depending on the type of test. Some of those tests are already being worked on\n> by Achu Luma.\n\nI think it would be interesting to know which of these 78 test-*.c\nfiles you would like to migrate first, especially as some of them\nmight not be worth migrating as you said earlier.\n\n\n> ----Timeline----\n>\n> Pre-GSoC\n> (Until May 1)\n> - Continue to work on different things like solving the bug discovered in the\n> first patch series that I sent. Be engaged in the community.\n>\n> Community Bonding\n> (May 1 - May 26)\n> - Talk with mentors and identify the tests which are suitable for migration.\n> Learn the libraries which are used for those tests and read up on the API.\n> Look at Achu Luma’s branches to further familiarize myself with the migration\n> process. Start the migration early with the mentors’ permission.\n>\n> Phase I\n> (May 27 - July 11)\n> - Continue implementing the tests in the unit testing framework with the\n> guidance of mentors and send out patches to the mailing list for community\n> approval. Approximately 6-7 tests would be done/cooking for migration at\n> the end of this Phase.\n>\n> Phase II\n> (July 12 - Aug 18)\n> - Continue the migration and talk with the mentors about the pace, quality of\n> patches and seek feedback. And enjoy the process. Another 5-6 tests would be\n> done/cooking at the end of this Phase.\n>\n> Final Week\n> (Aug 19 - Aug 26)\n> - Finish up any remaining tests.\n> - Fix any bugs and some final touches.\n> - Make a final report about the work accomplished and outline future work.\n>\n> ----Blogging----\n>\n> I believe that writing about one’s work helps them track their progress from a\n> bird’s eye view. And also helps them realize if they are making mistakes from a\n> long term perspective. I plan to blog about the progress bi-weekly. Although I\n> have not setup the blog yet, it will be at:\n> https://spectre10.github.io\n>\n> ----Availability----\n>\n> My current semester ends on 30th April and my exam/viva is tentatively on 7th\n> May. After that I have freed my summer for GSoC, therefore I will be able to\n> give a minimum of 35-40 hours per week.\n>\n> Post-GSoC\n> ---------\n>\n> The Git Community has helped me very much and tolerated my beginner mistakes.\n> I have grown as a developer since I started contributing to Git. I learned the\n> importance of writing good commit messages, benefits of splitting up patches,\n> effective programming style and good communication etiquettes. Therefore, I plan\n> to be involved even after my GSoC journey ends. I am very much involved in the\n> Git ecosystem and also contribute to another project in the Git ecosystem called\n> gittuf[5]. Also post-gsoc, I am planning to help out in aggregating for Git Rev\n> News, which I personally enjoy reading.\n>\n> My Appreciation\n> ---------------\n>\n> I would like extend my thanks to all of the folks on the mailing list and\n> Discord who have helped me in contributing to the Git Project including Junio,\n> Christian Couder, Phillip Wood, Elijah Newren and many others. And I have also\n> taken some references of Achu Luma’s work for this proposal, so thanks to\n> her, too.\n\n\n\n> -- After GSoC --\n> ---------------------\n>\n> After GSoC I intend to be a part of the community and keep\n> contributing to the git’s codebase. I eagerly want to learn a lot from\n> the git community and enhance my skills. I also see myself making\n> important contributions to git in the future.\n>\n> When I first joined the community 2 months ago, the ancient way of\n> collaborating through a mailing list by sending diff patches was\n> really puzzling (GitHub was the only means that I knew about for\n> open-source collaboration). After sending a patch I got a little\n> comfortable with it and started loving it.\n>\n> -- Closing remarks --\n> ----------------------------\n>\n> I am really enthusiastic to contribute to git. I really want to learn\n> a lot from my mentors and the whole git community. Everyone\n> contributes using git, why not contribute to git :).\n>\n> In the end I really want to thank the whole community, especially\n> Christian and Junio, for their valuable time in reviewing my patches\n> and guiding me with the problems I faced.\n\nThanks for your proposal. Please make sure you submit it soon as a pdf\nfile to the GSoC website. It can then be updated by uploading a new\npdf until the April 2 1800 UTC deadline.\n"},{"id":"491172","messageId":"20240321202218.13648-1-shyamthakkar001@gmail.com","threadId":"61158","inReplyTo":"CAP8UFD2COoXfDdS1eg5DR_0NL8bOhCHvXUkqkfzLbSejRmgwSw@mail.gmail.com","subject":"[GSoC][RFC][Proposal v2] Move existing tests to a unit testing framework","fromName":"Ghanshyam Thakkar","fromEmail":"shyamthakkar001@gmail.com","sentAt":"2024-03-21T20:21:49Z","receivedAt":"2024-03-21T20:22:39Z","isPatch":false,"sender":{"key":"shyamthakkar001@gmail.com","avatar":"https://avatars.githubusercontent.com/u/72698233?v=4"},"body":"Hello Christian,\n\nThank you for the review. I have made the changes as per your suggestions.\nFor your convenience, I have also attached the diff of the changes below.\nThe web version can be viewed at:\nhttps://docs.google.com/document/d/1wmosedy-UKd_mhAAjccv1qETO1q00s-npYj2m6g-Hd0/edit?usp=sharing\n\nI appreciate any feedback on this proposal.\n\nThanks.\n\n---\ndiff --git a/proposal b/proposal\nindex de751da..6ed42e0 100644\n--- a/proposal\n+++ b/proposal\n@@ -21,7 +21,7 @@ E-mail: shyamthakkar001@gmail.com\n Ph. No.: +91 7990974044\n \n Education: L.D. College of Engineering, Gujarat, India\n-Year: IV\n+Year: IV (Final Year)\n Degree: Bachelors in Electronics and\n Communications Engineering\n \n@@ -34,9 +34,10 @@ Overview\n \n Initially Git used to only rely on shell scripts to test the functionality\n usually deemed to be internal (e.g. libraries, functions etc.) This was achieved\n-through t/helper binaries which would take input via stdin and output through\n-stdout and the test scripts would consume those outputs. This translation is\n-costly due to the following reasons:\n+through t/helper binaries which would take input via stdin or we can also invoke\n+it from the command line via arguments and output through stdout and the test\n+scripts would consume those outputs. This translation is costly due to the\n+following reasons:\n \n - Each test script creates a new git repository which is many times not needed.\n See here[1] for example.\n@@ -108,7 +109,9 @@ have made, in chronological order:\n This patch added functionality to assume an empty tree when on an unborn\n branch to be able to use ‘restore –staged’. However, this was discontinued\n due to lack of community interest. In hindsight, I think that this would\n- have been an acceptable patch, had I described it well.\n+ have been an acceptable patch, had I described it well. However, I might\n+ pick this up again during the empty period of present till the start of\n+ GSoC.\n Mailing list thread:\n https://lore.kernel.org/git/20240206230357.1097505-2-shyamthakkar001@gmail.com/\n \n@@ -250,6 +253,34 @@ per week during the Community Bonding and Coding Phase. This may fluctuate\n depending on the type of test. Some of those tests are already being worked on\n by Achu Luma.\n \n+- Tests which might not be suitable for migration:\n+ As already mentioned in the Additional Notes section, some tests are not worth\n+ migrating. This is because some of these helper binaries provide general\n+ purpose utilities which are used in not just unit tests, but used elsewhere\n+ as well. An example of that would be test-ref-store.c. Just by grepping for\n+ ‘test-tool ref-store’, we can see that it is used in many test scripts which\n+ also include end-to-end tests. More examples of these would be test-genzeros\n+ and test-genrandom.\n+\n+- Tests which might be suitable for migration:\n+ On the other hand, a suitable candidate for the migration would generally just\n+ provide a certain output and that output is compared against an expected\n+ value. These would not include utility helpers as mentioned above. In these\n+ cases, the test script is usually just a layer to compare the output with the\n+ expected value, and has little test related logic in itself.\n+ test-example-decorate.c seems like a good straight-forward choice as their\n+ “BUG” calls can be replaced by test_msg calls in the new framework and their\n+ corresponding if conditions can become checks in the new framework. Also, this\n+ helper is not used anywhere besides a single call in t9004. Some more examples\n+ would be test-revision-walking.c (t0062), and while \n+ test-{oidmap, oidtree, hashmap}.c can be considered a bit large, those are\n+ very similar in nature to what I have already implemented for test-oidarray.c.\n+ And the majority of these outlined tests have been stable for a long time and\n+ have not had any meaningful change. Therefore, I would like to start with\n+ these tests with mentors’ consensus. Some other tests can also be identified\n+ with the help of mentors and those can also be done instead of the ones I\n+ outlined.\n+\n ----Timeline----\n \n Pre-GSoC\n@@ -294,8 +325,28 @@ have not setup the blog yet, it will be at:\n ----Availability----\n \n My current semester ends on 30th April and my exam/viva is tentatively on 7th\n-May. After that I have freed my summer for GSoC, therefore I will be able to\n-give a minimum of 35-40 hours per week.\n+Mayand I will graduate after the results are out in June. Therefore I will be\n+able to give a minimum of 35-40 hours per week after 7th May as I have not taken\n+up any responsibilities in the summer for the purpose of GSoC.\n+\n+----Stretch Goals----\n+\n+These goals may not be achieved during the GSoC period, however, these may come\n+in handy if the migration is done ahead of the schedule or it is determined that\n+the number of tests that need to be migrated are not sufficient to cover the\n+allocated GSoC period further down the line. These can also be done after the\n+GSoC period. (Note that these are just personal observations/ideas and may not\n+be accepted by mentors, hence '_Stretch_ Goals'.)\n+- Enhancement of the unit testing library. An example of the need of doing this\n+ would be t-ctype, which bypasses top-level macros such as TEST(), in favor of\n+ custom logic with the use of internal helper functions.\n+- Add more helper functions in the unit testing library such as handling and use\n+ of parameters defined by environment variables (which I personally faced in\n+ implementing t-oidarray.) I am sure there are other such utilities which might\n+ be worthwhile.\n+- Adding support for performance related testing through unit tests.\n+- Working in other areas of the codebase not related to unit testing or doing\n+ other tasks as specified by mentors.\n \n Post-GSoC\n ---------\n \n\n Here is the full proposal:\n-- >8 --\nMove existing tests to a unit testing framework\n\nPersonal Information\n--------------------\n\nName: Ghanshyam Thakkar\nE-mail: shyamthakkar001@gmail.com\nPh. No.: +91 7990974044\n\nEducation: L.D. College of Engineering, Gujarat, India\nYear: IV (Final Year)\nDegree: Bachelors in Electronics and\n Communications Engineering\n\nGitHub: https://github.com/spectre10\nTime-zone: UTC +5:30 (IST)\n\n\nOverview\n--------\n\nInitially Git used to only rely on shell scripts to test the functionality\nusually deemed to be internal (e.g. libraries, functions etc.) This was achieved\nthrough t/helper binaries which would take input via stdin or we can also invoke\nit from the command line via arguments and output through stdout and the test\nscripts would consume those outputs. This translation is costly due to the\nfollowing reasons:\n\n- Each test script creates a new git repository which is many times not needed.\n See here[1] for example.\n- These scripts spawn processes every time they need a certain output. And \n spawning processes are expensive (especially on windows).\n- Difficult setups: sometimes the functions or the libraries we are testing need\n some special setup such as defining flags for custom behavior etc. which\n cannot be done through the shell scripts, hence we might forego testing those\n conditions.\n\nMoving to the unit testing framework would give us many benefits such as\nincreased runtime performance, and therefore lower test duration and solves all\nof the above points. The choice of framework and the rationale behind it is\nthoroughly described in Documentation/technical/unit-tests.txt. Therefore, the\ngoal of this project is to move existing unit tests from t/helper/* and its\ncorresponding scripts to the new unit testing framework. And there has been work\ngoing on to do this by Outreachy intern Achu Luma.\n\nThe expected project difficulty is medium and the expected project size would be\n350 hours.\n\n\nPre-GSoC\n--------\nI initially got into Git’s codebase in December, 2023 and started my\ncontribution journey in January, 2024. I worked on mostly what I found\ninteresting and within my reach. Following is the list of contributions that I\nhave made, in chronological order:\n\n- [PATCH v6 0/2] t7501: add tests for --include, --only, --signoff\n Status: merged into master\n Merge Commit: 2be9ccf23e0592b83b78e719574e580e79db0375\n Description:\n This patch series added missing tests for --include, --only and --signoff\n options of git-commit. While working on this patch I accidentally reproduced\n a bug where in an untracked path provided to the commit command with -i\n would not error out. This was noticed by Junio. Therefore, this patch also\n included a TODO comment describing this bug.\n Mailing list thread:\n https://lore.kernel.org/git/20240109060417.1144647-2-shyamthakkar001@gmail.com\n\n- [PATCH v3 1/2] t0024: avoid losing exit status to pipes\n Status: merged into master\n Merge Commit: 40225ba8b494080d7f90dd5e129daa7b11c613d1\n Description:\n Although this was not my first contribution, it was done to fulfill the\n microproject criteria from the list of micro-projects on Git Developer\n Pages. The first patch replaces the pipe to the redirection operator to\n store the output to a temporary file to avoid losing exit status of the git\n commands. And the second patch of the series fixes the style violations to\n adhere to the current standard described in CodingGuidelines.\n Mailing list thread:\n https://lore.kernel.org/git/20240118215407.8609-1-shyamthakkar001@gmail.com/\n\n- [PATCH v6 0/2] add-patch: classify '@' as a synonym for 'HEAD'\n Status: merged into master\n Merge Commit: 65462776c2963b377968e580ace1590238bf79c1\n Description:\n The first patch of this series removed the disparity of command line output\n of using ‘HEAD’ vs ‘@’ in ‘git reset/restore/checkout -p’. And the second\n patch removed the perl prerequisites in the test scripts which use the patch\n mode functionality.\n Mailing list thread:\n https://lore.kernel.org/git/20240128181202.986753-2-shyamthakkar001@gmail.com/\n\n- [PATCH] restore: allow --staged on unborn branch\n Status: Discontinued\n Description:\n This patch added functionality to assume an empty tree when on an unborn\n branch to be able to use ‘restore –staged’. However, this was discontinued\n due to lack of community interest. In hindsight, I think that this would\n have been an acceptable patch, had I described it well. However, I might\n pick this up again during the empty period of present till the start of\n GSoC.\n Mailing list thread:\n https://lore.kernel.org/git/20240206230357.1097505-2-shyamthakkar001@gmail.com/\n\n- [PATCH] unit-tests: convert t/helper/test-oid-array.c to unit-tests\n Status: on hold until GSoC\n Description:\n This was used as a practice patch to the current project proposal. This will\n be used as a reference in the proposal ahead.\n Mailing list thread:\n https://lore.kernel.org/git/20240223193257.9222-1-shyamthakkar001@gmail.com/\n \n- [PATCH v2] setup: remove unnecessary variable\n Status: Merged to master\n Merge Commit: 272fd9125aae215ece1c465a4b7d336cf81c3e62\n Description:\n I initially proposed the TODO comment removed through this patch as a\n micro-project for my first patch. However, the TODO comment was a result of\n misunderstanding, therefore this patch did some minor code simplifications\n along with the removal of the TODO comment.\n Mailing list thread:\n https://lore.kernel.org/git/20240304151811.511780-1-shyamthakkar001@gmail.com/\n\n- [PATCH 0/2] commit, add: error out when passing untracked path \n Status: WIP\n Description:\n This patch series would fix the potential bug discovered in the first patch\n that I sent (--include tests).\n\tMailing list thread:\n https://lore.kernel.org/git/20240318155219.494206-2-shyamthakkar001@gmail.com/\n\n- Helped a fellow contributor by reviewing their patches\n Thread links:\n - https://lore.kernel.org/git/CZG3HO25QLAG.3Q9V03SCO99HL@gmail.com/\n - https://lore.kernel.org/git/CZHJPF604DV9.X0A0VX1AB7P8@gmail.com/\n\nProposed Project\n----------------\n\n----What’s unit testing----\n\nUnit testing is a method to test a specific unit of source code (i.e. a\nfunction, a module etc.). This is very helpful in catching all of the corner\ncases and possible scenarios.\n\n----Steps to convert the existing unit tests to the new framework----\n\nIt can be thought of as a series of steps which are outlined below:\n- Identify a suitable candidate from t/helper directory.\n- Each t/helper unit test has a corresponding shell script which actually tests\n the output from the binary. Each test-case in that script would ideally become\n a separate function (and therefore a single test-case) in the migrated unit\n test.\n- Convert the test logic from the shell script to C. This would involve\n understanding the underlying library/functionality which is being\n tested. Subsequently, make functions which would be ideally be a single\n testcase.\n- These functions can be called via the TEST() macro in the cmd_main\n function which is the entry point to the test.\n- Each of these functions contains a set of {check(), check_int() etc.} macro\n functions which check the condition provided to them and if it fails, prints\n a message to the stdout. If even a single check fails the whole test-case is\n considered a failure.\n- Modify Makefile to add the reference of the new test to the UNIT_TEST_PROGRAMS\n variable.\n- The skeleton of the new unit test would look something like this:\n\n #include \"test-lib.h\"\n\n static void testcase_1()\n {\n\t ...\n\t check(actual == expected);\n\t ...\n }\n\n int cmd_main(int argc, const char **argv)\n {\n\t TEST(testcase_1(), \"test description\");\n\t return test_done();\n }\n\n- After the migration remove the references of t/helper/{old-test-helper}.{c, o}\n from the Makefile and from the t/helper/test-tool.{c, h}. And subsequently\n remove the shell script which used to consume the old helper binary.\n\n----Additional Notes along with a Reference Implementation----\n\nThese tests usually contain duplicate logic with variations in input and output.\nIn such cases, we can define macro functions to not duplicate such logic. I.e.\nin t-ctype, we can see how a custom macro is defined to avoid duplication of\ntest logic, with variation only in the input being used. Also, some these\nexisting tests are not worth migrating. For example, test-tool binaries which\nare also used outside of the corresponding shell script (i.e. used in other\ntests for setup purposes) would be low on the priority list of possible\nmigrations.\n\nI have made a reference implementation of t-oid-array.c which migrates\nt/helper/test-oid-array.c and t/0064-oid-array.sh to the new framework, which\ncan be viewed here[2]. Note that the failing tests are not related to my\nimplementation and rather a known issue[3]. It may or may not to be good enough to\nbe merged into master, however it sufficiently showcases my abilities to\nunderstand framework, the use of different macros and the ability to understand\ndifferent internal libraries and data-structures such oidarray itself.\n\nThis implementation was also reviewed by Christian Couder on the mailing list\nand I have made some adjustments according to the feedback.\n\nThis implementation uses a macro to test the ordered enumeration of oidarray\nwith different inputs. And also tests the lookup capabilities of oidarray with\ndifferent queries and inputs with the help of a macro. There are also various\nhelper functions defined to help with printing debug output, generating\nhexadecimal representations, etc.\n\n----Previous Work----\n\nTAP implementation along with t-basic and t-strbuf:\nhttps://github.com/git/git/commit/e137fe3b\n\nt-mempool: https://github.com/git/git/commit/6cbae640\nt-ctype: https://github.com/git/git/commit/e875d451\nt-prio-queue: https://github.com/git/git/commit/808b77e5\n\nAchu Luma has been doing this migration as part of Outreachy internship. Their\nbranches can be seen here[4].\n\n----Goal----\n\nThe end goal of this project would be to migrate as many unit tests as possible\naccording to the steps outlined above. In doing so, also enhance some of the\ntests as needed to be extensible such as the ability to test different hash\nalgorithms on a single oidarray. This enhancement is not yet implemented in the\nreference implementation due to the series which enables the use of different\nhash algorithms on oidarray not yet merged into master (in next though).\n\nCurrently, there are 78 test-*.c files (not including test-tool.c) in t/helper/\ndirectory according to the master branch. Of course, migrating all of them would\nbe a difficult task in 350 hours, therefore I plan to migrate around 1 unit test\nper week during the Community Bonding and Coding Phase. This may fluctuate\ndepending on the type of test. Some of those tests are already being worked on\nby Achu Luma.\n\n- Tests which might not be suitable for migration:\n As already mentioned in the Additional Notes section, some tests are not worth\n migrating. This is because some of these helper binaries provide general\n purpose utilities which are used in not just unit tests, but used elsewhere\n as well. An example of that would be test-ref-store.c. Just by grepping for\n ‘test-tool ref-store’, we can see that it is used in many test scripts which\n also include end-to-end tests. More examples of these would be test-genzeros\n and test-genrandom.\n\n- Tests which might be suitable for migration:\n On the other hand, a suitable candidate for the migration would generally just\n provide a certain output and that output is compared against an expected\n value. These would not include utility helpers as mentioned above. In these\n cases, the test script is usually just a layer to compare the output with the\n expected value, and has little test related logic in itself.\n test-example-decorate.c seems like a good straight-forward choice as their\n “BUG” calls can be replaced by test_msg calls in the new framework and their\n corresponding if conditions can become checks in the new framework. Also, this\n helper is not used anywhere besides a single call in t9004. Some more examples\n would be test-revision-walking.c (t0062), and while \n test-{oidmap, oidtree, hashmap}.c can be considered a bit large, those are\n very similar in nature to what I have already implemented for test-oidarray.c.\n And the majority of these outlined tests have been stable for a long time and\n have not had any meaningful change. Therefore, I would like to start with\n these tests with mentors’ consensus. Some other tests can also be identified\n with the help of mentors and those can also be done instead of the ones I\n outlined.\n\n----Timeline----\n\nPre-GSoC\n(Until May 1)\n- Continue to work on different things like solving the bug discovered in the\n first patch series that I sent. Be engaged in the community.\n\nCommunity Bonding\n(May 1 - May 26)\n- Talk with mentors and identify the tests which are suitable for migration.\n Learn the libraries which are used for those tests and read up on the API.\n Look at Achu Luma’s branches to further familiarize myself with the migration\n process. Start the migration early with the mentors’ permission.\n \nPhase I\n(May 27 - July 11)\n- Continue implementing the tests in the unit testing framework with the\n guidance of mentors and send out patches to the mailing list for community\n approval. Approximately 6-7 tests would be done/cooking for migration at\n the end of this Phase.\n\nPhase II\n(July 12 - Aug 18)\n- Continue the migration and talk with the mentors about the pace, quality of\n patches and seek feedback. And enjoy the process. Another 5-6 tests would be\n done/cooking at the end of this Phase.\n \nFinal Week\n(Aug 19 - Aug 26)\n- Finish up any remaining tests.\n- Fix any bugs and some final touches.\n- Make a final report about the work accomplished and outline future work.\n\n----Blogging----\n\nI believe that writing about one’s work helps them track their progress from a\nbird’s eye view. And also helps them realize if they are making mistakes from a\nlong term perspective. I plan to blog about the progress bi-weekly. Although I\nhave not setup the blog yet, it will be at:\n https://spectre10.github.io\n \n----Availability----\n\nMy current semester ends on 30th April and my exam/viva is tentatively on 7th\nMayand I will graduate after the results are out in June. Therefore I will be\nable to give a minimum of 35-40 hours per week after 7th May as I have not taken\nup any responsibilities in the summer for the purpose of GSoC.\n\n----Stretch Goals----\n\nThese goals may not be achieved during the GSoC period, however, these may come\nin handy if the migration is done ahead of the schedule or it is determined that\nthe number of tests that need to be migrated are not sufficient to cover the\nallocated GSoC period further down the line. These can also be done after the\nGSoC period. (Note that these are just personal observations/ideas and may not\nbe accepted by mentors, hence '_Stretch_ Goals'.)\n- Enhancement of the unit testing library. An example of the need of doing this\n would be t-ctype, which bypasses top-level macros such as TEST(), in favor of\n custom logic with the use of internal helper functions.\n- Add more helper functions in the unit testing library such as handling and use\n of parameters defined by environment variables (which I personally faced in\n implementing t-oidarray.) I am sure there are other such utilities which might\n be worthwhile.\n- Adding support for performance related testing through unit tests.\n- Working in other areas of the codebase not related to unit testing or doing\n other tasks as specified by mentors.\n\nPost-GSoC\n---------\n\nThe Git Community has helped me very much and tolerated my beginner mistakes.\nI have grown as a developer since I started contributing to Git. I learned the\nimportance of writing good commit messages, benefits of splitting up patches,\neffective programming style and good communication etiquettes. Therefore, I plan\nto be involved even after my GSoC journey ends. I am very much involved in the\nGit ecosystem and also contribute to another project in the Git ecosystem called\ngittuf[5]. Also post-gsoc, I am planning to help out in aggregating for Git Rev\nNews, which I personally enjoy reading.\n\nMy Appreciation\n---------------\n\nI would like extend my thanks to all of the folks on the mailing list and\nDiscord who have helped me in contributing to the Git Project including Junio,\nChristian Couder, Phillip Wood, Elijah Newren and many others. And I have also\ntaken some references of Achu Luma’s work for this proposal, so thanks to\nher, too.\n\nThanks & Regards,\nGhanshyam\n\nReferences:\n[1], [2]: https://github.com/spectre10/git/commit/9bfbb22ced3c4d15a215a84aa40043a30dc1bac0\n[3]: https://lore.kernel.org/git/20240318090848.GC602575@coredump.intra.peff.net/T/#mc32405849ac4265ad36670480709d744f1d9e495\n[4]: https://github.com/achluma/git/branches\n[5]: https://github.com/gittuf/gittuf\n\n"},{"id":"491563","messageId":"CAP8UFD3xiGH72BRdQ=76npUKp8pCF+cLXoNYkUFUNKyejWDSAg@mail.gmail.com","threadId":"61158","inReplyTo":"20240321202218.13648-1-shyamthakkar001@gmail.com","subject":"Re: [GSoC][RFC][Proposal v2] Move existing tests to a unit testing framework","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2024-03-26T09:32:47Z","receivedAt":"2024-03-26T09:33:01Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Hi Ghanshyam,\n\nOn Thu, Mar 21, 2024 at 9:22 PM Ghanshyam Thakkar\n wrote:\n\n> @@ -294,8 +325,28 @@ have not setup the blog yet, it will be at:\n> ----Availability----\n>\n> My current semester ends on 30th April and my exam/viva is tentatively on 7th\n> -May. After that I have freed my summer for GSoC, therefore I will be able to\n> -give a minimum of 35-40 hours per week.\n> +Mayand I will graduate after the results are out in June. Therefore I will be\n\ns/Mayand/May and/\n\n> +able to give a minimum of 35-40 hours per week after 7th May as I have not taken\n> +up any responsibilities in the summer for the purpose of GSoC.\n\n\n> +----Stretch Goals----\n> +\n> +These goals may not be achieved during the GSoC period, however, these may come\n> +in handy if the migration is done ahead of the schedule or it is determined that\n> +the number of tests that need to be migrated are not sufficient to cover the\n> +allocated GSoC period further down the line. These can also be done after the\n> +GSoC period. (Note that these are just personal observations/ideas and may not\n> +be accepted by mentors, hence '_Stretch_ Goals'.)\n> +- Enhancement of the unit testing library. An example of the need of doing this\n> + would be t-ctype, which bypasses top-level macros such as TEST(), in favor of\n> + custom logic with the use of internal helper functions.\n> +- Add more helper functions in the unit testing library such as handling and use\n> + of parameters defined by environment variables (which I personally faced in\n> + implementing t-oidarray.) I am sure there are other such utilities which might\n> + be worthwhile.\n> +- Adding support for performance related testing through unit tests.\n> +- Working in other areas of the codebase not related to unit testing or doing\n> + other tasks as specified by mentors.\n\nThis makes me think that it would be nice if you or others interested\nin the \"Move existing tests to a unit testing framework\" project could\nreview Luma's patches that haven't been reviewed and merged yet. See\nthe \"Key Achievements\" in\nhttps://lumap.gitlab.io/posts/outreachy-internship-conclusion for\npointers to the patches.\n\nThanks for updating your proposal anyway. Except for the typo above,\nall the changes LGTM.\n"}]}