{"thread":{"id":"60299","subject":"[Outreachy] Move existing tests to a unit testing framework","startedAt":"2023-10-03T14:30:33Z","lastAt":"2023-10-25T08:19:07Z","messageCount":8,"participants":["Luma","Junio C Hamano","Achu Luma","Christian Couder"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"482568","messageId":"CAFR+8DynAJ7eieMYUrezoNii5tzARNbESFxRCcT4w6okS5FZDg@mail.gmail.com","threadId":"60299","inReplyTo":null,"subject":"[Outreachy] Move existing tests to a unit testing framework","fromName":"Luma","fromEmail":"ach.lumap@gmail.com","sentAt":"2023-10-03T14:30:18Z","receivedAt":"2023-10-03T14:30:33Z","isPatch":false,"sender":{"key":"ach.lumap@gmail.com","avatar":"https://avatars.githubusercontent.com/u/142904668?v=4"},"body":"Hi;\nMy name is Luma, and I wanted to take a moment to introduce myself\nand share some\ninsights on an essential aspect of avoiding pipes in git related\ncommands in test scripts.\n\nI am an outreachy applicant for the December 2023 cohort and look\nforward to learning from you.\n\nOne common practice in shell scripting is the use of pipes (|) to\nchain multiple commands together.\n While pipes are incredibly versatile and useful, excessive use of\nthem can lead to script complexity.\nI plan to avoid overusing pipes in test scripts by: leveraging command\noptions, using temporary files\nand using functions and variables to break down complex pipelines.\n\nIf you have any questions on pipes, I'm always here to learn and share\nknowledge.\n\nBest regards,\nLuma.\n"},{"id":"482593","messageId":"xmqqedibzgi1.fsf@gitster.g","threadId":"60299","inReplyTo":"CAFR+8DynAJ7eieMYUrezoNii5tzARNbESFxRCcT4w6okS5FZDg@mail.gmail.com","subject":"Re: [Outreachy] Move existing tests to a unit testing framework","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2023-10-03T18:51:34Z","receivedAt":"2023-10-03T18:51:40Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Luma writes:\n\n> Hi;\n> My name is Luma, and I wanted to take a moment to introduce myself\n> and share some\n> insights on an essential aspect of avoiding pipes in git related\n> commands in test scripts.\n>\n> I am an outreachy applicant for the December 2023 cohort and look\n> forward to learning from you.\n\nI notice that the title of the message and the immediate topic you\ndiscuss in the body of the message do not match. I presume that the\ntopic on the title is what you prefer to work on if the unit testing\nframework is ready by the time Outreachy program starts, and the\nmention about \"do not clobber exit code of Git with pipes in the\ntests\" is your \"dip the tip of a toe in water\" microproject?\n\nWelcome to the Git development community.\n\nDo you have a single word name? If so please disregard the below,\nbut in case \"Luma\" is just a nickname (e.g. like I am introducing\nmyself to my Git friends \"Hi, I am Gitster!\") you use online, please\nread on.\n\nFor signing off your patches, we'd prefer to see your real name\nused, as Signed-off-by: is meant to have legal significance. And\nbecause we also expect the authorship identity to match the\nname/e-mail of the sign-off, it would mean your patch submissions\nare expected to look like:\n\n\tFrom: Luma \n\tSubject: ... title of the patch goes here ...\n\n\t... body of the proposed commit log message goes here...\n\n\tSigned-off-by: Luma \n\nbut \"Luma\" replaced with your full real name.\n\nThanks.\n"},{"id":"482628","messageId":"CAFR+8DyN8vbuvdgZPkSVqS2=sqconwhx3QfcpJ0+Wi_oCA=s0w@mail.gmail.com","threadId":"60299","inReplyTo":"xmqqedibzgi1.fsf@gitster.g","subject":"Re: [Outreachy] Move existing tests to a unit testing framework","fromName":"Luma","fromEmail":"ach.lumap@gmail.com","sentAt":"2023-10-03T23:36:30Z","receivedAt":"2023-10-03T23:36:48Z","isPatch":false,"sender":{"key":"ach.lumap@gmail.com","avatar":"https://avatars.githubusercontent.com/u/142904668?v=4"},"body":"oh yes, \"Move existing tests to a unit testing framework\" was the\nonly listed project for this current Outreachy cohort. So, I used it\nto express my intent.\nI appreciate the clarification on authorship identity for patches. I\nwill update subsequent patches with a legal full name to conform to\nthe community rules.\n\nRegards.\n\nOn Tue, Oct 3, 2023 at 7:51 PM Junio C Hamano wrote:\n>\n> Luma writes:\n>\n> > Hi;\n> > My name is Luma, and I wanted to take a moment to introduce myself\n> > and share some\n> > insights on an essential aspect of avoiding pipes in git related\n> > commands in test scripts.\n> >\n> > I am an outreachy applicant for the December 2023 cohort and look\n> > forward to learning from you.\n>\n> I notice that the title of the message and the immediate topic you\n> discuss in the body of the message do not match. I presume that the\n> topic on the title is what you prefer to work on if the unit testing\n> framework is ready by the time Outreachy program starts, and the\n> mention about \"do not clobber exit code of Git with pipes in the\n> tests\" is your \"dip the tip of a toe in water\" microproject?\n>\n> Welcome to the Git development community.\n>\n> Do you have a single word name? If so please disregard the below,\n> but in case \"Luma\" is just a nickname (e.g. like I am introducing\n> myself to my Git friends \"Hi, I am Gitster!\") you use online, please\n> read on.\n>\n> For signing off your patches, we'd prefer to see your real name\n> used, as Signed-off-by: is meant to have legal significance. And\n> because we also expect the authorship identity to match the\n> name/e-mail of the sign-off, it would mean your patch submissions\n> are expected to look like:\n>\n> From: Luma \n> Subject: ... title of the patch goes here ...\n>\n> ... body of the proposed commit log message goes here...\n>\n> Signed-off-by: Luma \n>\n> but \"Luma\" replaced with your full real name.\n>\n> Thanks.\n"},{"id":"482851","messageId":"CAFR+8Dz717pcc2Lm_J29xxiBt-kUrMP4JAUbm=3XaJuJPYseHg@mail.gmail.com","threadId":"60299","inReplyTo":"CAFR+8DyN8vbuvdgZPkSVqS2=sqconwhx3QfcpJ0+Wi_oCA=s0w@mail.gmail.com","subject":"Re: [Outreachy] Move existing tests to a unit testing framework","fromName":"Luma","fromEmail":"ach.lumap@gmail.com","sentAt":"2023-10-09T09:15:02Z","receivedAt":"2023-10-09T09:15:15Z","isPatch":false,"sender":{"key":"ach.lumap@gmail.com","avatar":"https://avatars.githubusercontent.com/u/142904668?v=4"},"body":"Dear Git Community and Mentors,\n\nI hope this email finds you well. My name is Achu Luma, and I am\nexcited to submit my application for the Outreachy program with the\nGit project.\nI have been a passionate open-source enthusiast and a dedicated Git\nuser for two years, and I am thrilled at the opportunity to contribute\nto the Git community.\n\nIntroduction:\n----------------\nI study Computer Science from the University of Bamenda. Over the past\n4 years, I have gained experience in software development and have\nparticipated in various class projects.\n\nWhy I am a Good Fit:\n----------------------\n1. Proficient with Git: I have a good understanding of Git's version\ncontrol system and have successfully used it in both personal and\neducational projects.\n\n2. Strong Programming Skills: My programming skills in python, C etc\nand experience with git, shell etc make me well-prepared to contribute\nto Git's codebase.\n\n3. Open Source Involvement: I have actively contributed to git\nopen-source project, including\nhttps://public-inbox.org/git/20231003174853.1732-1-ach.lumap@gmail.com/T/#t\n, where I have submitted a patch that has been well-received.\n\nProject Idea - Moving Existing Tests to a Unit Testing Framework:\n------------------------------------------------------------------\nI am excited about \"Moving Existing Tests to a Unit Testing Framework\".\nThe objective of this project is to enhance the efficiency and\nmaintainability of Git's testing infrastructure by porting existing\nunit tests to a unit testing framework.\n\n**Project Plan**:\n- Evaluate the existing tests in the `t/helper/` directory to identify\nthose suitable for migration to the unit testing framework.\n- Develop a migration strategy and create detailed plans for adapting\nthese tests.\n- Port the identified tests to the unit testing framework while\nensuring they maintain their functionality.\n- Verify the correctness and reliability of the migrated tests through\nthorough testing and validation.\n- Collaborate with the Git community to gather feedback and make\nnecessary adjustments.\n\n**Timeline**:\n- Community Bonding (Oct 2 - Nov 20): Familiarize myself with the Git\nproject and establish communication channels.\n- Coding Phase (Dec 4 - Jan 15): Implement the migration of tests and\nseek feedback from mentors and the community.\n- Testing and Validation (Jan 15 - Feb 15): Rigorously test the\nmigrated tests and make improvements based on feedback.\n- Documentation and Finalization (Feb 15 - March 1): Document the\nmigration process and finalize the project.\n\n**Contribution to Git Community**:\nI have actively participated in Git's mailing-list discussions and\nsubmitted a patch(\nhttps://public-inbox.org/git/20231003174853.1732-1-ach.lumap@gmail.com/T/#t)\nfor review. I have received positive feedback on my contributions, and\nit has been queued to be merged into official Git branches maintained\nby Junio. Additionally, I have been involved in discussions related to\nthe git project.(https://public-inbox.org/git/CAFR+8DyN8vbuvdgZPkSVqS2=sqconwhx3QfcpJ0+Wi_oCA=s0w@mail.gmail.com/T/#t)\n\n**Proposal Drafts**:\nI have shared drafts of this proposal on the Git mailing list\ngit@vger.kernel.org and will incorporate valuable feedback provided\nby the community.\n\n**Next Steps**:\nI am eager to discuss my proposal further and collaborate with the Git\ncommunity to ensure the success of this project. I will continue to\nengage with the community, seek guidance, and refine my proposal as\nper your suggestions.\n\nThank you for considering my application. I look forward to the\nopportunity to contribute to the Git project and help make it even\nmore robust and reliable.\n\nBest Regards,\n\nOn Wed, Oct 4, 2023 at 12:36 AM Luma wrote:\n>\n> oh yes, \"Move existing tests to a unit testing framework\" was the\n> only listed project for this current Outreachy cohort. So, I used it\n> to express my intent.\n> I appreciate the clarification on authorship identity for patches. I\n> will update subsequent patches with a legal full name to conform to\n> the community rules.\n>\n> Regards.\n>\n> On Tue, Oct 3, 2023 at 7:51 PM Junio C Hamano wrote:\n> >\n> > Luma writes:\n> >\n> > > Hi;\n> > > My name is Luma, and I wanted to take a moment to introduce myself\n> > > and share some\n> > > insights on an essential aspect of avoiding pipes in git related\n> > > commands in test scripts.\n> > >\n> > > I am an outreachy applicant for the December 2023 cohort and look\n> > > forward to learning from you.\n> >\n> > I notice that the title of the message and the immediate topic you\n> > discuss in the body of the message do not match. I presume that the\n> > topic on the title is what you prefer to work on if the unit testing\n> > framework is ready by the time Outreachy program starts, and the\n> > mention about \"do not clobber exit code of Git with pipes in the\n> > tests\" is your \"dip the tip of a toe in water\" microproject?\n> >\n> > Welcome to the Git development community.\n> >\n> > Do you have a single word name? If so please disregard the below,\n> > but in case \"Luma\" is just a nickname (e.g. like I am introducing\n> > myself to my Git friends \"Hi, I am Gitster!\") you use online, please\n> > read on.\n> >\n> > For signing off your patches, we'd prefer to see your real name\n> > used, as Signed-off-by: is meant to have legal significance. And\n> > because we also expect the authorship identity to match the\n> > name/e-mail of the sign-off, it would mean your patch submissions\n> > are expected to look like:\n> >\n> > From: Luma \n> > Subject: ... title of the patch goes here ...\n> >\n> > ... body of the proposed commit log message goes here...\n> >\n> > Signed-off-by: Luma \n> >\n> > but \"Luma\" replaced with your full real name.\n> >\n> > Thanks.\n"},{"id":"483563","messageId":"CAFR+8Dx=0QMOcw8zvRL_+OzvJv5wt3F_t+FZqNvcB-rWqh3oFg@mail.gmail.com","threadId":"60299","inReplyTo":"CAFR+8Dwxr3iV+R7een0t2sYXUWu1XHhQcLVuqMhOsSg9Bt4wrg@mail.gmail.com","subject":"Re: [Outreachy] Move existing tests to a unit testing framework","fromName":"Achu Luma","fromEmail":"ach.lumap@gmail.com","sentAt":"2023-10-20T13:18:34Z","receivedAt":"2023-10-20T13:18:49Z","isPatch":false,"sender":{"key":"ach.lumap@gmail.com","avatar":"https://avatars.githubusercontent.com/u/142904668?v=4"},"body":"Dear Git Community and Mentors,\n\nI hope this email finds you well. As a follow-up to my previous\napplication, I'd like to provide additional details on the process of\nmigrating existing unit tests from the t/helper/ directory to the new\nGit unit test framework.\n-- Identify Target Unit Tests: Start by identifying the specific unit\ntests in the t/helper/ directory that we want to port to the new Git\nunit test framework. Ensure that the tests are suitable for migration\nand that the benefits of doing so outweigh the effort(By avoiding\nintegration tests). The following points have been developed with on\ngoing work on the unit-tests framework visible here: 1-\nhttps://lore.kernel.org/git/0169ce6fb9ccafc089b74ae406db0d1a8ff8ac65.1688165272.git.steadmon@google.com/\n2- https://github.com/steadmon/git/blob/unit-tests-asciidoc/Documentation/technical/unit-tests.adoc\n\n-- Create a New C Test File: For each unit test I plan to migrate,\ncreate a new C source file (.c) in the Git project's test suite\ndirectory(t/unit-tests). Name it appropriately to reflect the purpose\nof the test.\n\n-- Include Necessary Headers:In the new C test file, include the\nnecessary Git unit test framework headers. Typically, this includes\nheaders like \"test-lib.h\" and others relevant to the specific test.\n#include \"test-lib.h\"\n\n-- Convert Test Logic: Refactor the test logic from the original Shell\nscript into the new C-based test format. Use the testing macros\nprovided by the Git unit test framework, such as test_expect_success,\ntest_expect_failure, etc., to define the tests.\ntest_expect_success(\"simple progress display\", \"{\n // Test logic here...\n}\");\n\n-- Add Test Descriptions: Provide clear and informative descriptions\nfor each test using the testing macros. These descriptions will help\nin identifying the purpose of each test when the test suite is run.\n\n-- Define a Test Entry Point: Create a cmd_main function as the entry\npoint for the C-based tests. Inside this function, include the test\nfunctions using the testing macros.\nint cmd_main(int argc, const char **argv) {\n // Test functions...\n return test_done();\n}\n\n-- Ensure TAP Format Output: Ensure that the C-based tests produce\noutput in the Test Anything Protocol (TAP) format. This format\nincludes the test name, status (ok or not ok), and any diagnostic\ninformation.\n\n-- Test Interaction: Ensure that the migrated tests interact correctly\nwith the new Git unit test framework and any other tests that may be\nrelevant. Consider dependencies and interactions with other parts of\nthe Git project.\n\n-- Test Execution: Run the migrated tests to verify that they produce\nthe expected results when executed as part of the Git project's test\nsuite. Use the Git testing framework's test runners to execute the\ntests.\n\n-- Documentation Update: Update the Git project's documentation to\nreflect the changes made during the migration. Include a reference to\nthe original unit tests in the t/helper/ directory and indicate that\nthese tests have been ported to the new Git unit test framework.\n\nBy following these points, I think I can successfully port existing\nunit tests from the t/helper/ directory to use the new Git unit test\nframework. This migration helps standardize and streamline the testing\nprocess within the Git project, improving code quality and\nmaintainability.\n\nNext Steps:\n\nI am eager to discuss these suggestions and collaborate with the Git\ncommunity to ensure the success of this project. I will continue to\nengage with the community, seek guidance, and refine my proposal as\nper your suggestions.\n I look forward to the opportunity to contribute to the Git project\nand help make it even more robust and reliable.\n\nBest Regards,\nAchu Luma\n\n\nOn Fri, Oct 20, 2023 at 2:15 PM Achu Luma wrote:\n>\n> Dear Git Community and Mentors,\n>\n> I hope this email finds you well. As a follow-up to my previous application, I'd like to provide additional details on the process of migrating existing unit tests from the t/helper/ directory to the new Git unit test framework.\n> -- Identify Target Unit Tests: Start by identifying the specific unit tests in the t/helper/ directory that we want to port to the new Git unit test framework. Ensure that the tests are suitable for migration and that the benefits of doing so outweigh the effort(By avoiding integration tests). The following points have been developed with on going work on the unit-tests framework visible here: 1- https://lore.kernel.org/git/0169ce6fb9ccafc089b74ae406db0d1a8ff8ac65.1688165272.git.steadmon@google.com/\n> 2- https://github.com/steadmon/git/blob/unit-tests-asciidoc/Documentation/technical/unit-tests.adoc\n>\n> -- Create a New C Test File: For each unit test I plan to migrate, create a new C source file (.c) in the Git project's test suite directory(t/unit-tests). Name it appropriately to reflect the purpose of the test.\n>\n> -- Include Necessary Headers:In the new C test file, include the necessary Git unit test framework headers. Typically, this includes headers like \"test-lib.h\" and others relevant to the specific test.\n> #include \"test-lib.h\"\n>\n> -- Convert Test Logic: Refactor the test logic from the original Shell script into the new C-based test format. Use the testing macros provided by the Git unit test framework, such as test_expect_success, test_expect_failure, etc., to define the tests.\n> test_expect_success(\"simple progress display\", \"{\n> // Test logic here...\n> }\");\n>\n> -- Add Test Descriptions: Provide clear and informative descriptions for each test using the testing macros. These descriptions will help in identifying the purpose of each test when the test suite is run.\n>\n> -- Define a Test Entry Point: Create a cmd_main function as the entry point for the C-based tests. Inside this function, include the test functions using the testing macros.\n> int cmd_main(int argc, const char **argv) {\n> // Test functions...\n> return test_done();\n> }\n>\n> -- Ensure TAP Format Output: Ensure that the C-based tests produce output in the Test Anything Protocol (TAP) format. This format includes the test name, status (ok or not ok), and any diagnostic information.\n>\n> -- Test Interaction: Ensure that the migrated tests interact correctly with the new Git unit test framework and any other tests that may be relevant. Consider dependencies and interactions with other parts of the Git project.\n>\n> -- Test Execution: Run the migrated tests to verify that they produce the expected results when executed as part of the Git project's test suite. Use the Git testing framework's test runners to execute the tests.\n>\n> -- Documentation Update: Update the Git project's documentation to reflect the changes made during the migration. Include a reference to the original unit tests in the t/helper/ directory and indicate that these tests have been ported to the new Git unit test framework.\n>\n> By following these points, I think I can successfully port existing unit tests from the t/helper/ directory to use the new Git unit test framework. This migration helps standardize and streamline the testing process within the Git project, improving code quality and maintainability.\n>\n> Next Steps:\n>\n> I am eager to discuss these suggestions and collaborate with the Git community to ensure the success of this project. I will continue to engage with the community, seek guidance, and refine my proposal as per your suggestions.\n> I look forward to the opportunity to contribute to the Git project and help make it even more robust and reliable.\n>\n> Best Regards,\n> Achu Luma\n>\n> On Mon, Oct 9, 2023 at 10:15 AM Luma wrote:\n>>\n>> Dear Git Community and Mentors,\n>>\n>> I hope this email finds you well. My name is Achu Luma, and I am\n>> excited to submit my application for the Outreachy program with the\n>> Git project.\n>> I have been a passionate open-source enthusiast and a dedicated Git\n>> user for two years, and I am thrilled at the opportunity to contribute\n>> to the Git community.\n>>\n>> Introduction:\n>> ----------------\n>> I study Computer Science from the University of Bamenda. Over the past\n>> 4 years, I have gained experience in software development and have\n>> participated in various class projects.\n>>\n>> Why I am a Good Fit:\n>> ----------------------\n>> 1. Proficient with Git: I have a good understanding of Git's version\n>> control system and have successfully used it in both personal and\n>> educational projects.\n>>\n>> 2. Strong Programming Skills: My programming skills in python, C etc\n>> and experience with git, shell etc make me well-prepared to contribute\n>> to Git's codebase.\n>>\n>> 3. Open Source Involvement: I have actively contributed to git\n>> open-source project, including\n>> https://public-inbox.org/git/20231003174853.1732-1-ach.lumap@gmail.com/T/#t\n>> , where I have submitted a patch that has been well-received.\n>>\n>> Project Idea - Moving Existing Tests to a Unit Testing Framework:\n>> ------------------------------------------------------------------\n>> I am excited about \"Moving Existing Tests to a Unit Testing Framework\".\n>> The objective of this project is to enhance the efficiency and\n>> maintainability of Git's testing infrastructure by porting existing\n>> unit tests to a unit testing framework.\n>>\n>> **Project Plan**:\n>> - Evaluate the existing tests in the `t/helper/` directory to identify\n>> those suitable for migration to the unit testing framework.\n>> - Develop a migration strategy and create detailed plans for adapting\n>> these tests.\n>> - Port the identified tests to the unit testing framework while\n>> ensuring they maintain their functionality.\n>> - Verify the correctness and reliability of the migrated tests through\n>> thorough testing and validation.\n>> - Collaborate with the Git community to gather feedback and make\n>> necessary adjustments.\n>>\n>> **Timeline**:\n>> - Community Bonding (Oct 2 - Nov 20): Familiarize myself with the Git\n>> project and establish communication channels.\n>> - Coding Phase (Dec 4 - Jan 15): Implement the migration of tests and\n>> seek feedback from mentors and the community.\n>> - Testing and Validation (Jan 15 - Feb 15): Rigorously test the\n>> migrated tests and make improvements based on feedback.\n>> - Documentation and Finalization (Feb 15 - March 1): Document the\n>> migration process and finalize the project.\n>>\n>> **Contribution to Git Community**:\n>> I have actively participated in Git's mailing-list discussions and\n>> submitted a patch(\n>> https://public-inbox.org/git/20231003174853.1732-1-ach.lumap@gmail.com/T/#t)\n>> for review. I have received positive feedback on my contributions, and\n>> it has been queued to be merged into official Git branches maintained\n>> by Junio. Additionally, I have been involved in discussions related to\n>> the git project.(https://public-inbox.org/git/CAFR+8DyN8vbuvdgZPkSVqS2=sqconwhx3QfcpJ0+Wi_oCA=s0w@mail.gmail.com/T/#t)\n>>\n>> **Proposal Drafts**:\n>> I have shared drafts of this proposal on the Git mailing list\n>> git@vger.kernel.org and will incorporate valuable feedback provided\n>> by the community.\n>>\n>> **Next Steps**:\n>> I am eager to discuss my proposal further and collaborate with the Git\n>> community to ensure the success of this project. I will continue to\n>> engage with the community, seek guidance, and refine my proposal as\n>> per your suggestions.\n>>\n>> Thank you for considering my application. I look forward to the\n>> opportunity to contribute to the Git project and help make it even\n>> more robust and reliable.\n>>\n>> Best Regards,\n>>\n>> On Wed, Oct 4, 2023 at 12:36 AM Luma wrote:\n>> >\n>> > oh yes, \"Move existing tests to a unit testing framework\" was the\n>> > only listed project for this current Outreachy cohort. So, I used it\n>> > to express my intent.\n>> > I appreciate the clarification on authorship identity for patches. I\n>> > will update subsequent patches with a legal full name to conform to\n>> > the community rules.\n>> >\n>> > Regards.\n>> >\n>> > On Tue, Oct 3, 2023 at 7:51 PM Junio C Hamano wrote:\n>> > >\n>> > > Luma writes:\n>> > >\n>> > > > Hi;\n>> > > > My name is Luma, and I wanted to take a moment to introduce myself\n>> > > > and share some\n>> > > > insights on an essential aspect of avoiding pipes in git related\n>> > > > commands in test scripts.\n>> > > >\n>> > > > I am an outreachy applicant for the December 2023 cohort and look\n>> > > > forward to learning from you.\n>> > >\n>> > > I notice that the title of the message and the immediate topic you\n>> > > discuss in the body of the message do not match. I presume that the\n>> > > topic on the title is what you prefer to work on if the unit testing\n>> > > framework is ready by the time Outreachy program starts, and the\n>> > > mention about \"do not clobber exit code of Git with pipes in the\n>> > > tests\" is your \"dip the tip of a toe in water\" microproject?\n>> > >\n>> > > Welcome to the Git development community.\n>> > >\n>> > > Do you have a single word name? If so please disregard the below,\n>> > > but in case \"Luma\" is just a nickname (e.g. like I am introducing\n>> > > myself to my Git friends \"Hi, I am Gitster!\") you use online, please\n>> > > read on.\n>> > >\n>> > > For signing off your patches, we'd prefer to see your real name\n>> > > used, as Signed-off-by: is meant to have legal significance. And\n>> > > because we also expect the authorship identity to match the\n>> > > name/e-mail of the sign-off, it would mean your patch submissions\n>> > > are expected to look like:\n>> > >\n>> > > From: Luma \n>> > > Subject: ... title of the patch goes here ...\n>> > >\n>> > > ... body of the proposed commit log message goes here...\n>> > >\n>> > > Signed-off-by: Luma \n>> > >\n>> > > but \"Luma\" replaced with your full real name.\n>> > >\n>> > > Thanks.\n"},{"id":"483668","messageId":"CAP8UFD0A_vWCZ5cVAZqdTBebdhZNye_FmNNJF+vA7epUx2JWHQ@mail.gmail.com","threadId":"60299","inReplyTo":"CAFR+8Dwxr3iV+R7een0t2sYXUWu1XHhQcLVuqMhOsSg9Bt4wrg@mail.gmail.com","subject":"Re: [Outreachy] Move existing tests to a unit testing framework","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2023-10-23T13:41:05Z","receivedAt":"2023-10-23T13:41:21Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Fri, Oct 20, 2023 at 3:16 PM Achu Luma wrote:\n>\n> Dear Git Community and Mentors,\n>\n> I hope this email finds you well. As a follow-up to my previous application, I'd like to provide additional details on the process of migrating existing unit tests from the t/helper/ directory to the new Git unit test framework.\n\nThanks for these details!\n\n> -- Identify Target Unit Tests: Start by identifying the specific unit tests in the t/helper/ directory that we want to port to the new Git unit test framework. Ensure that the tests are suitable for migration and that the benefits of doing so outweigh the effort(By avoiding integration tests). The following points have been developed with on going work on the unit-tests framework visible here:\n>\n> 1- https://lore.kernel.org/git/0169ce6fb9ccafc089b74ae406db0d1a8ff8ac65.1688165272.git.steadmon@google.com/\n> 2- https://github.com/steadmon/git/blob/unit-tests-asciidoc/Documentation/technical/unit-tests.adoc\n\nMaybe if you have time you could add some descriptions or comments\nrelated to the above emails and documents. For example you could tell\nwhat the new unit test framework will be like, how the unit tests will\nlook like, etc. Maybe a short overview would be nice.\n\nYou could also try to apply the patches in the series that adds the\ntest framework, or alternatively use the 'seen' branch where the\nseries has been merged, and start playing with it by writing, or\nporting, a small example test.\n\n> -- Create a New C Test File: For each unit test I plan to migrate, create a new C source file (.c) in the Git project's test suite directory(t/unit-tests). Name it appropriately to reflect the purpose of the test.\n\nCould you provide an example of what the new name would be for an\nexisting test that is worth porting?\n\n> -- Include Necessary Headers:In the new C test file, include the necessary Git unit test framework headers. Typically, this includes headers like \"test-lib.h\" and others relevant to the specific test.\n> #include \"test-lib.h\"\n\nMaybe you could continue the above example and tell which headers\nwould be needed for it?\n\n> -- Convert Test Logic: Refactor the test logic from the original Shell script into the new C-based test format. Use the testing macros provided by the Git unit test framework, such as test_expect_success, test_expect_failure, etc., to define the tests.\n> test_expect_success(\"simple progress display\", \"{\n> // Test logic here...\n> }\");\n\nOk, a simple example would be nice too.\n\n> -- Add Test Descriptions: Provide clear and informative descriptions for each test using the testing macros. These descriptions will help in identifying the purpose of each test when the test suite is run.\n\nThis would seem to be part of the previous step, as you would have to\nprovide a description when using the testing macro. But Ok.\n\n> -- Define a Test Entry Point: Create a cmd_main function as the entry point for the C-based tests. Inside this function, include the test functions using the testing macros.\n> int cmd_main(int argc, const char **argv) {\n> // Test functions...\n> return test_done();\n> }\n\nYeah, continuing an example would be nice.\n\n> -- Ensure TAP Format Output: Ensure that the C-based tests produce output in the Test Anything Protocol (TAP) format. This format includes the test name, status (ok or not ok), and any diagnostic information.\n\nThat means using TEST* macros in the cmd_main() function, as they\nshould do the right thing or is there more to be done here?\n\n> -- Test Interaction: Ensure that the migrated tests interact correctly with the new Git unit test framework and any other tests that may be relevant. Consider dependencies and interactions with other parts of the Git project.\n\nI am not sure what work would be needed here. Is there more to do than\ncompiling the test files? Having an example would be nice.\n\n> -- Test Execution: Run the migrated tests to verify that they produce the expected results when executed as part of the Git project's test suite. Use the Git testing framework's test runners to execute the tests.\n\nOk.\n\n> -- Documentation Update: Update the Git project's documentation to reflect the changes made during the migration. Include a reference to the original unit tests in the t/helper/ directory and indicate that these tests have been ported to the new Git unit test framework.\n\nI am not sure that we would want that. I think we might instead want\nto document things in t/helper/ that we don't want to port to the new\nunit test framework and why.\n\n> By following these points, I think I can successfully port existing unit tests from the t/helper/ directory to use the new Git unit test framework. This migration helps standardize and streamline the testing process within the Git project, improving code quality and maintainability.\n\nYeah!\n\n> Next Steps:\n>\n> I am eager to discuss these suggestions and collaborate with the Git community to ensure the success of this project. I will continue to engage with the community, seek guidance, and refine my proposal as per your suggestions.\n> I look forward to the opportunity to contribute to the Git project and help make it even more robust and reliable.\n\nThanks for this application and sorry for the late answer!\n\nBest,\nChristian.\n"},{"id":"483796","messageId":"CAFR+8DzdFbwaiHtZSdLMqWYWh=fK0WA4c48+eBug-ZeAgddhcQ@mail.gmail.com","threadId":"60299","inReplyTo":"CAP8UFD0A_vWCZ5cVAZqdTBebdhZNye_FmNNJF+vA7epUx2JWHQ@mail.gmail.com","subject":"Re: [Outreachy] Move existing tests to a unit testing framework","fromName":"Achu Luma","fromEmail":"ach.lumap@gmail.com","sentAt":"2023-10-24T14:25:26Z","receivedAt":"2023-10-24T14:25:40Z","isPatch":false,"sender":{"key":"ach.lumap@gmail.com","avatar":"https://avatars.githubusercontent.com/u/142904668?v=4"},"body":"On Mon, Oct 23, 2023 at 2:41 PM Christian Couder\n wrote:\n>\n> On Fri, Oct 20, 2023 at 3:16 PM Achu Luma wrote:\n> >\n> > Dear Git Community and Mentors,\n> >\n> > I hope this email finds you well. As a follow-up to my previous application, I'd like to provide additional details on the process of migrating existing unit tests from the t/helper/ directory to the new Git unit test framework.\n>\n> Thanks for these details!\n>\n> > -- Identify Target Unit Tests: Start by identifying the specific unit tests in the t/helper/ directory that we want to port to the new Git unit test framework. Ensure that the tests are suitable for migration and that the benefits of doing so outweigh the effort(By avoiding integration tests). The following points have been developed with on going work on the unit-tests framework visible here:\n> >\n> > 1- https://lore.kernel.org/git/0169ce6fb9ccafc089b74ae406db0d1a8ff8ac65.1688165272.git.steadmon@google.com/\n> > 2- https://github.com/steadmon/git/blob/unit-tests-asciidoc/Documentation/technical/unit-tests.adoc\n>\n> Maybe if you have time you could add some descriptions or comments\n> related to the above emails and documents. For example you could tell\n> what the new unit test framework will be like, how the unit tests will\n> look like, etc. Maybe a short overview would be nice.\n>\nsure,\n1- https://lore.kernel.org/git/0169ce6fb9ccafc089b74ae406db0d1a8ff8ac65.1688165272.git.steadmon@google.com/\n:\n The emails highlight the significant milestones achieved in\ndefining and testing the custom TAP\n framework for writing git unit tests. It also contains some\nexamples of implementation such as\n that of STRBUF_INIT with output:\n ok 1 - static initialization works\n 1..1\n\n2- https://github.com/steadmon/git/blob/unit-tests-asciidoc/Documentation/technical/unit-tests.adoc:\n From this technical doc, the new unit test framework in the Git\nproject represents a significant\n enhancement, introducing a systematic and efficient approach to\nunit testing. The custom git\n TAP implementation was selected from several alternatives based\non strict criteria as the most\n suitable test framework for porting the unit tests.\n The unit tests are written in pure C, eliminating the need for\nthe previous shell/test-tool helper\n setup, simplifying test configuration, data handling, and\nreducing testing runtime.\n Each unit test is encapsulated as a function and employs a range\nof predefined check functions\n for validation. These checks can evaluate conditions, compare\nintegers or characters, validate\n strings, and more, providing comprehensive coverage for test scenarios.\n\n When a test is run using the TEST() macro, it undergoes a series\nof checks, and if any check fails,\n a diagnostic message is printed to aid in debugging. This\ndiagnostic output includes information\n about the specific check that failed, the file and line number\nwhere it occurred, and a clear comparison\n of the expected and actual values. Such detailed reporting\nsimplifies the identification and resolution\n of issues, contributing to codebase stability.\n\n Additionally, the framework supports features like skipping tests\nwith explanations, sending custom\n diagnostic messages using test_msg(), and marking known-to-fail\nchecks using TEST_TODO().\n This flexibility allows developers to tailor their tests to\nspecific scenarios while ensuring a\n comprehensive testing suite.\n\n> You could also try to apply the patches in the series that adds the\n> test framework, or alternatively use the 'seen' branch where the\n> series has been merged, and start playing with it by writing, or\n> porting, a small example test.\n>\nok, I think I can push a patch for one.\n> > -- Create a New C Test File: For each unit test I plan to migrate, create a new C source file (.c) in the Git project's test suite directory(t/unit-tests). Name it appropriately to reflect the purpose of the test.\n>\n> Could you provide an example of what the new name would be for an\n> existing test that is worth porting?\n>\nSure... let's consider an existing unit test in t/helper directory\nsuch as t/helper/test-date.c or\nits shell named t0006-date.sh, which is part of the current\nshell-based test suite. In the context\nof the new unit testing framework, this test could be reimagined and renamed as\n\"t-date.c\". The \"t-\" prefix is typically used for test program files\nin Git, and \"date\" is retained to\n reflect the nature of the tests within this suite.\n> > -- Include Necessary Headers:In the new C test file, include the necessary Git unit test framework headers. Typically, this includes headers like \"test-lib.h\" and others relevant to the specific test.\n> > #include \"test-lib.h\"\n>\n> Maybe you could continue the above example and tell which headers\n> would be needed for it?\n>\n> > -- Convert Test Logic: Refactor the test logic from the original Shell script into the new C-based test format. Use the testing macros provided by the Git unit test framework, such as test_expect_success, test_expect_failure, etc., to define the tests.\n> > test_expect_success(\"simple progress display\", \"{\n> > // Test logic here...\n> > }\");\n>\n> Ok, a simple example would be nice too.\n>\nwe can continue with the example used for naming: test-date.c. a\ntypical t-date.c unit test would look\nlike the following:\n--\n#include \"test-lib.h\"\n#include \"date.h\"\n--\ndate.h here is a necessary header file. Now refactoring the test logic\nfrom the original shell script:\n--\n#include \"test-lib.h\"\n#include \"date.h\"\n\nstatic void test_parse_dates(void)\n{\n const char *dates[] = { \"invalid_date\", \"2023-10-17 10:00:00 +0200\", NULL };\n\n for (const char **argv = dates; *argv; argv++) {\n check_int(parse_dates((const char *[]){ *argv, NULL }), 0);\n }\n}\n--\n\n> > -- Add Test Descriptions: Provide clear and informative descriptions for each test using the testing macros. These descriptions will help in identifying the purpose of each test when the test suite is run.\n>\n> This would seem to be part of the previous step, as you would have to\n> provide a description when using the testing macro. But Ok.\n>\n> > -- Define a Test Entry Point: Create a cmd_main function as the entry point for the C-based tests. Inside this function, include the test functions using the testing macros.\n> > int cmd_main(int argc, const char **argv) {\n> > // Test functions...\n> > return test_done();\n> > }\n>\n> Yeah, continuing an example would be nice.\n>\nContinuing, we can add a test entrance as follows:\n--\n#include \"test-lib.h\"\n#include \"date.h\"\n\nstatic void test_parse_dates(void)\n{\n const char *dates[] = { \"invalid_date\", \"2023-10-17 10:00:00 +0200\", NULL };\n\n for (const char **argv = dates; *argv; argv++) {\n check_int(parse_dates((const char *[]){ *argv, NULL }), 0);\n }\n}\n\nint main(int argc UNUSED, const char **argv UNUSED)\n{\n TEST(test_parse_dates, \"Test date parsing\");\n\n return test_done();\n}\n--\n\nA typical unit tests with the custom TAP framework would look\nsomething like above. This might run in theory\nbut I have not yet run it as I used it here just for demonstration.\nThe unit tests can be built using\n\"make unit-tests.\" Additionally, Makefile can be modified to add the\nfile to the build:\n--\nUNIT_TEST_PROGRAMS += t-date\n--\n> > -- Ensure TAP Format Output: Ensure that the C-based tests produce output in the Test Anything Protocol (TAP) format. This format includes the test name, status (ok or not ok), and any diagnostic information.\n>\n> That means using TEST* macros in the cmd_main() function, as they\n> should do the right thing or is there more to be done here?\n>\n> > -- Test Interaction: Ensure that the migrated tests interact correctly with the new Git unit test framework and any other tests that may be relevant. Consider dependencies and interactions with other parts of the Git project.\n>\n> I am not sure what work would be needed here. Is there more to do than\n> compiling the test files? Having an example would be nice.\n>\n> > -- Test Execution: Run the migrated tests to verify that they produce the expected results when executed as part of the Git project's test suite. Use the Git testing framework's test runners to execute the tests.\n>\n> Ok.\n>\n> > -- Documentation Update: Update the Git project's documentation to reflect the changes made during the migration. Include a reference to the original unit tests in the t/helper/ directory and indicate that these tests have been ported to the new Git unit test framework.\n>\n> I am not sure that we would want that. I think we might instead want\n> to document things in t/helper/ that we don't want to port to the new\n> unit test framework and why.\n>\nOk noted.\n> > By following these points, I think I can successfully port existing unit tests from the t/helper/ directory to use the new Git unit test framework. This migration helps standardize and streamline the testing process within the Git project, improving code quality and maintainability.\n>\n> Yeah!\n>\n> > Next Steps:\n> >\n> > I am eager to discuss these suggestions and collaborate with the Git community to ensure the success of this project. I will continue to engage with the community, seek guidance, and refine my proposal as per your suggestions.\n> > I look forward to the opportunity to contribute to the Git project and help make it even more robust and reliable.\n>\n> Thanks for this application and sorry for the late answer!\n>\n> Best,\n> Christian.\n\nI look forward to feedback and better understanding of the new testing\nframework.\n\nBR,\nAchu Luma.\n"},{"id":"483843","messageId":"CAP8UFD0jJF6dPkC4yu1wtLXLsUg7HqT8oV6yiHzxgxe-mhQaJQ@mail.gmail.com","threadId":"60299","inReplyTo":"CAFR+8DzdFbwaiHtZSdLMqWYWh=fK0WA4c48+eBug-ZeAgddhcQ@mail.gmail.com","subject":"Re: [Outreachy] Move existing tests to a unit testing framework","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2023-10-25T08:18:51Z","receivedAt":"2023-10-25T08:19:07Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Tue, Oct 24, 2023 at 4:25 PM Achu Luma wrote:\n>\n> On Mon, Oct 23, 2023 at 2:41 PM Christian Couder\n> wrote:\n\n> > Maybe if you have time you could add some descriptions or comments\n> > related to the above emails and documents. For example you could tell\n> > what the new unit test framework will be like, how the unit tests will\n> > look like, etc. Maybe a short overview would be nice.\n> >\n> sure,\n> 1- https://lore.kernel.org/git/0169ce6fb9ccafc089b74ae406db0d1a8ff8ac65.1688165272.git.steadmon@google.com/\n> :\n> The emails highlight the significant milestones achieved in\n> defining and testing the custom TAP\n> framework for writing git unit tests. It also contains some\n> examples of implementation such as\n> that of STRBUF_INIT with output:\n> ok 1 - static initialization works\n> 1..1\n>\n> 2- https://github.com/steadmon/git/blob/unit-tests-asciidoc/Documentation/technical/unit-tests.adoc:\n> From this technical doc, the new unit test framework in the Git\n> project represents a significant\n> enhancement, introducing a systematic and efficient approach to\n> unit testing. The custom git\n> TAP implementation was selected from several alternatives based\n> on strict criteria as the most\n> suitable test framework for porting the unit tests.\n> The unit tests are written in pure C, eliminating the need for\n> the previous shell/test-tool helper\n> setup, simplifying test configuration, data handling, and\n> reducing testing runtime.\n> Each unit test is encapsulated as a function and employs a range\n> of predefined check functions\n> for validation. These checks can evaluate conditions, compare\n> integers or characters, validate\n> strings, and more, providing comprehensive coverage for test scenarios.\n>\n> When a test is run using the TEST() macro, it undergoes a series\n> of checks, and if any check fails,\n> a diagnostic message is printed to aid in debugging. This\n> diagnostic output includes information\n> about the specific check that failed, the file and line number\n> where it occurred, and a clear comparison\n> of the expected and actual values. Such detailed reporting\n> simplifies the identification and resolution\n> of issues, contributing to codebase stability.\n>\n> Additionally, the framework supports features like skipping tests\n> with explanations, sending custom\n> diagnostic messages using test_msg(), and marking known-to-fail\n> checks using TEST_TODO().\n> This flexibility allows developers to tailor their tests to\n> specific scenarios while ensuring a\n> comprehensive testing suite.\n\nOk, please add all these explanations above as well as those below to\nyour application document. We prefer that you consider your\napplication document like a patch. So you would send to the mailing\nlist several versions of it for review before submitting officially.\n\n> > You could also try to apply the patches in the series that adds the\n> > test framework, or alternatively use the 'seen' branch where the\n> > series has been merged, and start playing with it by writing, or\n> > porting, a small example test.\n> >\n> ok, I think I can push a patch for one.\n\nI don't think it's necessary to send it to the mailing list for now,\nbut it should definitely be part of your application document.\n\n> > > -- Create a New C Test File: For each unit test I plan to migrate, create a new C source file (.c) in the Git project's test suite directory(t/unit-tests). Name it appropriately to reflect the purpose of the test.\n> >\n> > Could you provide an example of what the new name would be for an\n> > existing test that is worth porting?\n> >\n> Sure... let's consider an existing unit test in t/helper directory\n> such as t/helper/test-date.c or\n> its shell named t0006-date.sh, which is part of the current\n> shell-based test suite. In the context\n> of the new unit testing framework, this test could be reimagined and renamed as\n> \"t-date.c\". The \"t-\" prefix is typically used for test program files\n> in Git, and \"date\" is retained to\n> reflect the nature of the tests within this suite.\n\nOk.\n\n> > > -- Include Necessary Headers:In the new C test file, include the necessary Git unit test framework headers. Typically, this includes headers like \"test-lib.h\" and others relevant to the specific test.\n> > > #include \"test-lib.h\"\n> >\n> > Maybe you could continue the above example and tell which headers\n> > would be needed for it?\n> >\n> > > -- Convert Test Logic: Refactor the test logic from the original Shell script into the new C-based test format. Use the testing macros provided by the Git unit test framework, such as test_expect_success, test_expect_failure, etc., to define the tests.\n> > > test_expect_success(\"simple progress display\", \"{\n> > > // Test logic here...\n> > > }\");\n> >\n> > Ok, a simple example would be nice too.\n> >\n> we can continue with the example used for naming: test-date.c. a\n> typical t-date.c unit test would look\n> like the following:\n> --\n> #include \"test-lib.h\"\n> #include \"date.h\"\n> --\n> date.h here is a necessary header file. Now refactoring the test logic\n> from the original shell script:\n> --\n> #include \"test-lib.h\"\n> #include \"date.h\"\n>\n> static void test_parse_dates(void)\n> {\n> const char *dates[] = { \"invalid_date\", \"2023-10-17 10:00:00 +0200\", NULL };\n>\n> for (const char **argv = dates; *argv; argv++) {\n> check_int(parse_dates((const char *[]){ *argv, NULL }), 0);\n> }\n> }\n> --\n\nNice!\n\n> > > -- Add Test Descriptions: Provide clear and informative descriptions for each test using the testing macros. These descriptions will help in identifying the purpose of each test when the test suite is run.\n> >\n> > This would seem to be part of the previous step, as you would have to\n> > provide a description when using the testing macro. But Ok.\n> >\n> > > -- Define a Test Entry Point: Create a cmd_main function as the entry point for the C-based tests. Inside this function, include the test functions using the testing macros.\n> > > int cmd_main(int argc, const char **argv) {\n> > > // Test functions...\n> > > return test_done();\n> > > }\n> >\n> > Yeah, continuing an example would be nice.\n> >\n> Continuing, we can add a test entrance as follows:\n> --\n> #include \"test-lib.h\"\n> #include \"date.h\"\n>\n> static void test_parse_dates(void)\n> {\n> const char *dates[] = { \"invalid_date\", \"2023-10-17 10:00:00 +0200\", NULL };\n>\n> for (const char **argv = dates; *argv; argv++) {\n> check_int(parse_dates((const char *[]){ *argv, NULL }), 0);\n> }\n> }\n>\n> int main(int argc UNUSED, const char **argv UNUSED)\n> {\n> TEST(test_parse_dates, \"Test date parsing\");\n>\n> return test_done();\n> }\n> --\n>\n> A typical unit tests with the custom TAP framework would look\n> something like above. This might run in theory\n> but I have not yet run it as I used it here just for demonstration.\n> The unit tests can be built using\n> \"make unit-tests.\" Additionally, Makefile can be modified to add the\n> file to the build:\n> --\n> UNIT_TEST_PROGRAMS += t-date\n> --\n\nGreat!\n\nThanks,\nChristian.\n"}]}