On Thu, Oct 19, 2023 at 10:25 AM Isoken Ibizugbe <isokenjune@xxxxxxxxx> wrote: > > Dear Git Community and Mentors, > > I hope you're doing well. I'm excited to share my application draft > for the Outreachy program with the Git project. Your feedback is > invaluable, and I'm eager to align the project with the community's > needs. Please review the attached draft and share your insights. > > Thank you for your support. Hello Christian, I would appreciate a review from you. > > Project Application > ---- > > About Me: > > My name is Isoken June Ibizugbe, my language is primarily English, and > I am a resident of Nigeria. I am a student at an online coding school > called African Leadership Xcelerator (ALX), participating in the > software engineering program. > > What project am I applying for? > > Moving Existing Tests to a Unit Testing Framework > > Why am I interested in working with the Git chosen project? > > Git has been a cornerstone for software development, enabling > developers worldwide to collaborate, innovate, and create exceptional > software. I would say without Git, my journey to pursuing my software > engineering career would be impossible, as I use it almost every day. > Yet, in this constantly evolving landscape, there is always room for > improvement, even in a well-established project. The Git project > currently relies on end-to-end tests, and this is where I see an > opportunity to make a profound impact. Being able to test libraries in > isolation via unit tests or mocks speeds up determining the root cause > of bugs. I am deeply passionate about contributing to this project and > firmly believe in the power of open-source software and the collective > intelligence of the community. A successful completion of this project > will significantly improve Git's testing capabilities and bring the > benefits of fewer errors, faster work and better testing for all > parts. > > My motivation for joining the Git community stemmed from my desire to > immerse myself in the world of open-source software and, ultimately, > to become a part of the Outreachy program. My time spent contributing > to Git has been nothing short of transformative. It has been a > remarkable learning experience that has introduced me to a new form of > collaboration using a mailing list and contributing through patches > rather than the typical Pull Request (PR). This collaborative > atmosphere has been pivotal in my growth as a developer, and I am > eager to continue this journey, making meaningful contributions to > this remarkable open-source project. > > Contributions to Git > > I have actively participated in Git's mailing list discussions and > contributed to a micro-project; > > - builtin/branch.c: Adjust error messages such as die(), error(), and > warning() messages used in branch, to conform to coding guidelines > (https://lore.kernel.org/git/20231019084052.567922-1-isokenjune@xxxxxxxxx/) > - Implemented changes to fix broken tests based on reviews from the > community (https://lore.kernel.org/git/20231019084052.567922-1-isokenjune@xxxxxxxxx/) > - In review. > > Project Goals: > > - Improve Testing Efficiency: Transitioning from end-to-end tests to > unit tests will enable more efficient testing of error conditions. > - Codebase Stability: Unit tests enhance code stability and facilitate > easier debugging through isolation. > - Simplify Testing: Writing unit tests in pure C simplifies test > setup, data passing, and reduces testing runtime by eliminating > separate processes for each test. > > Project Milestones: > > - Add useful tests of library-like code > - Integrate with stdlib work > - Run alongside regular make test target > > Project Timeline: > > 1. Oct 2 - Nov 20: Community Bonding > > - Understanding the structure of Git > - Getting familiar with the code > > 2. Dec 4 - Jan 15: Add useful tests of library-like code > > - Identify and document the current state of the tests in the Git > t/helper directory. > - Confirm the licensing and compatibility requirements for the chosen > unit testing framework. > - Develop unit tests for these library-like components. > - Execute the tests and ensure they cover various scenarios, including > error conditions. > - Run the tests and address any initial issues or bugs to ensure they > work as intended. > - Document the new tests and their coverage. > - Seek feedback and support from mentors and the Git community > > 3. Jan 15 - Feb 15: Integrate with Stdlib Work > > - Collaborate with the team working on standard library integration. > - Ensure that the tests for library-like code align with stdlib work. > - Verify that the tests effectively check the compatibility and > interaction of the code with standard libraries. > - Gather feedback and insights from the Git community on the > integrated tests, addressing any concerns or suggestions. > > 4. Feb 15 - March 1: Run Alongside Regular 'make test' Target and finalize > > - Configure the testing framework to run alongside the regular 'make > test' target. > - Ensure that the new tests are included in the standard testing suite. > - Execute 'make test' with the new tests and verify that they pass successfully. > - Document the integration process and how the new tests are included > in the standard testing procedure. > - Perform comprehensive testing of the entire unit testing framework. > - Ensure all migrated tests are working correctly within the new framework. > - Document the entire process of migrating Git's tests > - Prepare a final project report > > Technical Requirements > > According to the documentation on the unit test project > (https://github.com/steadmon/git/blob/unit-tests-asciidoc/Documentation/technical/unit-tests.adoc), > the suggested best framework for the Git project is the "Custom TAP > framework" (Phillip Wood's TAP implementation), as it aligns with > Git's licensing requirements, is vendorable, and can be customized by > Git's developers as needed, but it may require some additional > development work for features like parallel execution and mock > support, but it offers a strong foundation for unit testing within the > Git project. > > Relevant Projects > > Simple shell - A project based on emulating a shell. It was a > collaborative project which we managed using Git. > (https://github.com/Junie06/simple_shell). > This project was written in C, which allowed me to apply my C language > knowledge, essential for Git projects. > I'm proficient in using Shell for scripting, redirections, and > permissions, as shown in my work > (https://github.com/Junie06/alx-system_engineering-devops). > Creating the simple shell project deepened my understanding of how > shells work, and I even attempted to replicate a shell environment. > Collaborating on the Simple Shell project reinforced my Git skills.
