Dear Git Community and Mentors, 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. -- 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@xxxxxxxxxx/ 2- https://github.com/steadmon/git/blob/unit-tests-asciidoc/Documentation/technical/unit-tests.adoc -- 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. -- 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. #include "test-lib.h" -- 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. test_expect_success("simple progress display", "{ // Test logic here... }"); -- 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. -- 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. int cmd_main(int argc, const char **argv) { // Test functions... return test_done(); } -- 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. -- 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. -- 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. -- 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. 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. Next Steps: 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. I look forward to the opportunity to contribute to the Git project and help make it even more robust and reliable. Best Regards, Achu Luma On Fri, Oct 20, 2023 at 2:15 PM Achu Luma <ach.lumap@xxxxxxxxx> wrote: > > Dear Git Community and Mentors, > > 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. > -- 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@xxxxxxxxxx/ > 2- https://github.com/steadmon/git/blob/unit-tests-asciidoc/Documentation/technical/unit-tests.adoc > > -- 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. > > -- 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. > #include "test-lib.h" > > -- 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. > test_expect_success("simple progress display", "{ > // Test logic here... > }"); > > -- 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. > > -- 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. > int cmd_main(int argc, const char **argv) { > // Test functions... > return test_done(); > } > > -- 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. > > -- 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. > > -- 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. > > -- 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. > > 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. > > Next Steps: > > 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. > I look forward to the opportunity to contribute to the Git project and help make it even more robust and reliable. > > Best Regards, > Achu Luma > > On Mon, Oct 9, 2023 at 10:15 AM Luma <ach.lumap@xxxxxxxxx> wrote: >> >> Dear Git Community and Mentors, >> >> I hope this email finds you well. My name is Achu Luma, and I am >> excited to submit my application for the Outreachy program with the >> Git project. >> I have been a passionate open-source enthusiast and a dedicated Git >> user for two years, and I am thrilled at the opportunity to contribute >> to the Git community. >> >> Introduction: >> ---------------- >> I study Computer Science from the University of Bamenda. Over the past >> 4 years, I have gained experience in software development and have >> participated in various class projects. >> >> Why I am a Good Fit: >> ---------------------- >> 1. Proficient with Git: I have a good understanding of Git's version >> control system and have successfully used it in both personal and >> educational projects. >> >> 2. Strong Programming Skills: My programming skills in python, C etc >> and experience with git, shell etc make me well-prepared to contribute >> to Git's codebase. >> >> 3. Open Source Involvement: I have actively contributed to git >> open-source project, including >> https://public-inbox.org/git/20231003174853.1732-1-ach.lumap@xxxxxxxxx/T/#t >> , where I have submitted a patch that has been well-received. >> >> Project Idea - Moving Existing Tests to a Unit Testing Framework: >> ------------------------------------------------------------------ >> I am excited about "Moving Existing Tests to a Unit Testing Framework". >> The objective of this project is to enhance the efficiency and >> maintainability of Git's testing infrastructure by porting existing >> unit tests to a unit testing framework. >> >> **Project Plan**: >> - Evaluate the existing tests in the `t/helper/` directory to identify >> those suitable for migration to the unit testing framework. >> - Develop a migration strategy and create detailed plans for adapting >> these tests. >> - Port the identified tests to the unit testing framework while >> ensuring they maintain their functionality. >> - Verify the correctness and reliability of the migrated tests through >> thorough testing and validation. >> - Collaborate with the Git community to gather feedback and make >> necessary adjustments. >> >> **Timeline**: >> - Community Bonding (Oct 2 - Nov 20): Familiarize myself with the Git >> project and establish communication channels. >> - Coding Phase (Dec 4 - Jan 15): Implement the migration of tests and >> seek feedback from mentors and the community. >> - Testing and Validation (Jan 15 - Feb 15): Rigorously test the >> migrated tests and make improvements based on feedback. >> - Documentation and Finalization (Feb 15 - March 1): Document the >> migration process and finalize the project. >> >> **Contribution to Git Community**: >> I have actively participated in Git's mailing-list discussions and >> submitted a patch( >> https://public-inbox.org/git/20231003174853.1732-1-ach.lumap@xxxxxxxxx/T/#t) >> for review. I have received positive feedback on my contributions, and >> it has been queued to be merged into official Git branches maintained >> by Junio. Additionally, I have been involved in discussions related to >> the git project.(https://public-inbox.org/git/CAFR+8DyN8vbuvdgZPkSVqS2=sqconwhx3QfcpJ0+Wi_oCA=s0w@xxxxxxxxxxxxxx/T/#t) >> >> **Proposal Drafts**: >> I have shared drafts of this proposal on the Git mailing list >> git@xxxxxxxxxxxxxxx and will incorporate valuable feedback provided >> by the community. >> >> **Next Steps**: >> I am eager to discuss my proposal further 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. >> >> Thank you for considering my application. I look forward to the >> opportunity to contribute to the Git project and help make it even >> more robust and reliable. >> >> Best Regards, >> >> On Wed, Oct 4, 2023 at 12:36 AM Luma <ach.lumap@xxxxxxxxx> wrote: >> > >> > oh yes, "Move existing tests to a unit testing framework" was the >> > only listed project for this current Outreachy cohort. So, I used it >> > to express my intent. >> > I appreciate the clarification on authorship identity for patches. I >> > will update subsequent patches with a legal full name to conform to >> > the community rules. >> > >> > Regards. >> > >> > On Tue, Oct 3, 2023 at 7:51 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: >> > > >> > > Luma <ach.lumap@xxxxxxxxx> writes: >> > > >> > > > Hi; >> > > > My name is Luma, and I wanted to take a moment to introduce myself >> > > > and share some >> > > > insights on an essential aspect of avoiding pipes in git related >> > > > commands in test scripts. >> > > > >> > > > I am an outreachy applicant for the December 2023 cohort and look >> > > > forward to learning from you. >> > > >> > > I notice that the title of the message and the immediate topic you >> > > discuss in the body of the message do not match. I presume that the >> > > topic on the title is what you prefer to work on if the unit testing >> > > framework is ready by the time Outreachy program starts, and the >> > > mention about "do not clobber exit code of Git with pipes in the >> > > tests" is your "dip the tip of a toe in water" microproject? >> > > >> > > Welcome to the Git development community. >> > > >> > > Do you have a single word name? If so please disregard the below, >> > > but in case "Luma" is just a nickname (e.g. like I am introducing >> > > myself to my Git friends "Hi, I am Gitster!") you use online, please >> > > read on. >> > > >> > > For signing off your patches, we'd prefer to see your real name >> > > used, as Signed-off-by: is meant to have legal significance. And >> > > because we also expect the authorship identity to match the >> > > name/e-mail of the sign-off, it would mean your patch submissions >> > > are expected to look like: >> > > >> > > From: Luma <ach.lumap@xxxxxxxxx> >> > > Subject: ... title of the patch goes here ... >> > > >> > > ... body of the proposed commit log message goes here... >> > > >> > > Signed-off-by: Luma <ach.lumap@xxxxxxxxx> >> > > >> > > but "Luma" replaced with your full real name. >> > > >> > > Thanks.
