[RFC][Outreachy] Seeking Git Community Feedback on My Application

[RFC][Outreachy] Seeking Git Community Feedback on My Application

[Isoken Ibizugbe]

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.

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@gmail.com/)
- Implemented changes to fix broken tests based on reviews from the
community (https://lore.kernel.org/git/20231019084052.567922-1-isokenjune@gmail.com/)
- 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.

Re: [RFC][Outreachy] Seeking Git Community Feedback on My Application

[Isoken Ibizugbe]

On Thu, Oct 19, 2023 at 10:25 AM Isoken Ibizugbe <isokenjune@gmail.com> 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@gmail.com/)
> - Implemented changes to fix broken tests based on reviews from the
> community (https://lore.kernel.org/git/20231019084052.567922-1-isokenjune@gmail.com/)
> - 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.

Re: [RFC][Outreachy] Seeking Git Community Feedback on My Application

[Christian Couder]

On Thu, Oct 19, 2023 at 11:26 AM Isoken Ibizugbe <isokenjune@gmail.com> 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.

Thanks for your project application!

[...]

> 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.

Ok.

[...]

> 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@gmail.com/)
> - Implemented changes to fix broken tests based on reviews from the
> community (https://lore.kernel.org/git/20231019084052.567922-1-isokenjune@gmail.com/)
> - In review.

Nice!

> 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.

Ok.

> Project Milestones:
>
> - Add useful tests of library-like code
> - Integrate with stdlib work

Not sure what you call "stdlib" here.

> - 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

I think some of this time is also spent on working on a microproject,
writing an application and perhaps doing other things that regular Git
developers do.

> 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.

It would be nice if you could already take a look at that and tell us
about it in your application. There are different things in t/helper.
Some are worth porting and others are not. You might not want (or have
time to) to classify everything right now, but if you can identify a
few of each kind, and use those, or just one of them, as an example,
that would be great.

> - Confirm the licensing and compatibility requirements for the chosen
> unit testing framework.

I think those who have been working on the unit test framework have
already done this.

> - Develop unit tests for these library-like components.

Not sure what are "these library-like components". An example would
perhaps help.

> - 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.

Ok.

> - Document the new tests and their coverage.

What kind of documentation would that be?

> - 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.

Not sure what "standard library". Actually, maybe you are talking
about the goal of having a "standard library" implementation for Git
which is described in this report from the Virtual Contributor's
Summit:

https://lore.kernel.org/git/ZRrfN2lbg14IOLiK@nand.local/

It's true that the unit test framework would help with that goal. So
yeah maybe you will have to collaborate with the team working on that
goal. I am not sure at what step the work on this library will be when
the internship will start though.

> - 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.

Ok, but I think it would be more interesting to follow the steps with
an example test.

> 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.

I think others will likely take care of that sooner.

> - 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

Ok, but here also following an example test would be more interesting.

> 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.

Yeah, right. Thanks for summarizing that document!

> 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.

Ok, nice!

Best,
Christian.

Re: [RFC][Outreachy] Seeking Git Community Feedback on My Application

[Isoken Ibizugbe]

On Mon, Oct 23, 2023 at 3:24 PM Christian Couder
<christian.couder@gmail.com> wrote:
>
> On Thu, Oct 19, 2023 at 11:26 AM Isoken Ibizugbe <isokenjune@gmail.com> 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.
>
> Thanks for your project application!
>
> [...]
>
> > 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.
>
> Ok.
>
> [...]
>
> > 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@gmail.com/)
> > - Implemented changes to fix broken tests based on reviews from the
> > community (https://lore.kernel.org/git/20231019084052.567922-1-isokenjune@gmail.com/)
> > - In review.
>
> Nice!
>
> > 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.
>
> Ok.
>
> > Project Milestones:
> >
> > - Add useful tests of library-like code
> > - Integrate with stdlib work
>
> Not sure what you call "stdlib" here.
>
> > - 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
>
> I think some of this time is also spent on working on a microproject,
> writing an application and perhaps doing other things that regular Git
> developers do.
>
> > 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.
>
> It would be nice if you could already take a look at that and tell us
> about it in your application. There are different things in t/helper.
> Some are worth porting and others are not. You might not want (or have
> time to) to classify everything right now, but if you can identify a
> few of each kind, and use those, or just one of them, as an example,
> that would be great.
>
> > - Confirm the licensing and compatibility requirements for the chosen
> > unit testing framework.
>
> I think those who have been working on the unit test framework have
> already done this.

Thank you for the review. I have made changes to the project plan and
it emphasizes the critical tasks of identifying, selecting, and
porting tests, making it more concise and aligned with the project's
scope.

- Community Bonding (Oct 2 - Nov 20): Microproject contribution, Git
project application, get familiar with the Git codebase and testing
ecosystem.
-Identify and Select Tests: Identify and prioritize tests worth
porting, and document the selected tests. (I would classify tests that
are worth porting according to the following for now;

Relevance: Prioritize tests that are relevant to the current Git codebase.
Coverage: Focus on tests that cover core functionality or critical code paths.
Usage Frequency: Port tests that are frequently used or run in Git's
development process.
Isolation: Choose tests that can be easily ported and run independently.

- Write Unit Tests: Write unit tests for the identified test cases
using the Git custom test framework.
- Port Existing Tests: Port selected test cases from the t/helper
directory to the unit testing framework, by modifying them to work
within the custom TAP framework.
- Test Execution and Debugging: Execute the newly written unit tests
and the ported tests using the test framework.
- Seek Feedback: Share the progress with mentors and the Git
community, and address any concerns or suggestions provided by the
community.
- Documentation and Reporting: Document the entire process of
migrating Git's tests to the unit testing framework, and prepare a
final project report summarizing the work done, challenges faced, and
lessons learned.

What is the custom TAP framework?

According to this patch
(https://lore.kernel.org/git/ca284c575ece0aee7149641d5fb1977ccd7e7873.1692229626.git.steadmon@google.com/)
by Phillip Wood, which contains an example implementation for writing
unit tests with TAP output. The custom TAP framework is a Test
Anything Protocol (TAP) framework that allows for clear reporting of
test results, aiding in debugging and troubleshooting.

The framework contains the following features:

- Test Structure: Unit tests are defined as functions containing
multiple checks. The tests are run using the TEST() macro. If any
checks within a test fail, the entire test is marked as failed.
- Output Format: The output of the test program follows the TAP
format. It includes a series of messages describing the test's status.
For passed tests, it reports "ok," and for failed tests, it reports
"not ok." Each test is numbered, e.g., "ok 1 - static initialization
works," to indicate success or failure.
- Check Functions: Several check functions are available, including
check() for boolean conditions, check_int(), check_uint(), and
check_char() for comparing values using various operators. check_str()
is used to compare strings.
- Skipping Tests: Tests can be skipped using test_skip() and can
include a reason for skipping, which is printed as part of the report.
- Diagnostic Messages: Tests can generate diagnostic messages using
test_msg() to provide additional context or explanations for test
failures.
- Planned Failing Tests: Tests that are known to fail can be marked
with TEST_TODO(). These tests will still run, and the failures will be
reported, but they will not cause the entire suite to fail.
- Building and Running: The unit tests can be built with "make
unit-tests" (with some additional Makefile changes), and they can be
executed manually or using a tool like prove.

Using the formerly given criteria, test-ctype.c is suitable for
porting because it tests character type checks used extensively in
Git. These tests cover various character types and their expected
behaviour, ensuring the correctness and reliability of Git's
operations, and test-ctype.c isolation makes it suitable for porting
without relying on multiple libraries.


Here is a sample of the implementation of how I would write the unit
test following the custom TAP framework taking t/helper/test-ctype.c

- Create and rename the new .c file;
I would rename it according to the convention done in the t/unit-test
directory, by starting the name with a “t-” prefix e.g t-ctype.c

- Document the tests and include the necessary headers:
/**
 *Tests the behavior of ctype
 *functions
*/
#include "test-lib.h"
#include "ctype.h"

- Define test functions:
#define DIGIT "0123456789"

static void t_digit_type(void)
{
    int i;
    const char *digits = DIGIT;
    for (i = 0; digits[i]; i++)
   {
         check_int(isdigit(digits[i]), ==, 0);
   }

- Include main function which will call the test functions using the TEST macro;
int main(void)
{
    TEST(t_digit_type(), "Character is a digit");
    return test_done();
}

- Run the tests:
‘make && make’ unit-tests can be used build and run the unit tests
Or run the test binaries directly:
./t/unit-tests/t-ctype.c

The Makefile will be modified to add the file;
UNIT_TEST_PROGRAMS += t-ctype
The test output will be in the TAP format and will indicate which
tests passed(ok) and which failed(not ok), along with diagnostic
messages in case of failures.

ok 1 - Character is a digit

1..1

>
> > - Develop unit tests for these library-like components.
>
> Not sure what are "these library-like components". An example would
> perhaps help.
>
> > - 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.
>
> Ok.
>
> > - Document the new tests and their coverage.
>
> What kind of documentation would that be?
>
> > - 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.
>
> Not sure what "standard library". Actually, maybe you are talking
> about the goal of having a "standard library" implementation for Git
> which is described in this report from the Virtual Contributor's
> Summit:
>
> https://lore.kernel.org/git/ZRrfN2lbg14IOLiK@nand.local/
>
> It's true that the unit test framework would help with that goal. So
> yeah maybe you will have to collaborate with the team working on that
> goal. I am not sure at what step the work on this library will be when
> the internship will start though.
>
> > - 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.
>
> Ok, but I think it would be more interesting to follow the steps with
> an example test.
>
> > 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.
>
> I think others will likely take care of that sooner.
>
> > - 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
>
> Ok, but here also following an example test would be more interesting.

>
> > 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.
>
> Yeah, right. Thanks for summarizing that document!
>
> > 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.
>
> Ok, nice!
>
> Best,
> Christian.

Re: [RFC][Outreachy] Seeking Git Community Feedback on My Application

[Christian Couder]

On Wed, Oct 25, 2023 at 2:46 PM Isoken Ibizugbe <isokenjune@gmail.com> wrote:

> Thank you for the review. I have made changes to the project plan and
> it emphasizes the critical tasks of identifying, selecting, and
> porting tests, making it more concise and aligned with the project's
> scope.

Good.

> - Community Bonding (Oct 2 - Nov 20): Microproject contribution, Git
> project application, get familiar with the Git codebase and testing
> ecosystem.
> -Identify and Select Tests: Identify and prioritize tests worth
> porting, and document the selected tests. (I would classify tests that
> are worth porting according to the following for now;
>
> Relevance: Prioritize tests that are relevant to the current Git codebase.
> Coverage: Focus on tests that cover core functionality or critical code paths.
> Usage Frequency: Port tests that are frequently used or run in Git's
> development process.
> Isolation: Choose tests that can be easily ported and run independently.

I think the main issue with identification is that now in t/helper/ we
have both:

  1) code that implements helpers that are used by the end-to-end
tests scripts written in shell and named "t/tXXXX-*.sh" where XXXX is
a number, and
  2) code that implements unit tests for some C code in the code base.

So I think only 2) should be ported to the unit test framework, and 1)
should not be ported and stay in t/helper/.

> - Write Unit Tests: Write unit tests for the identified test cases
> using the Git custom test framework.
> - Port Existing Tests: Port selected test cases from the t/helper
> directory to the unit testing framework, by modifying them to work
> within the custom TAP framework.
> - Test Execution and Debugging: Execute the newly written unit tests
> and the ported tests using the test framework.
> - Seek Feedback: Share the progress with mentors and the Git
> community, and address any concerns or suggestions provided by the
> community.
> - Documentation and Reporting: Document the entire process of
> migrating Git's tests to the unit testing framework, and prepare a
> final project report summarizing the work done, challenges faced, and
> lessons learned.
>
> What is the custom TAP framework?
>
> According to this patch
> (https://lore.kernel.org/git/ca284c575ece0aee7149641d5fb1977ccd7e7873.1692229626.git.steadmon@google.com/)
> by Phillip Wood, which contains an example implementation for writing
> unit tests with TAP output. The custom TAP framework is a Test
> Anything Protocol (TAP) framework that allows for clear reporting of
> test results, aiding in debugging and troubleshooting.

Ok. Our end-to-end tests scripts written in shell already use TAP,
that's why it's nice to have unit tests also using TAP.

> The framework contains the following features:
>
> - Test Structure: Unit tests are defined as functions containing
> multiple checks. The tests are run using the TEST() macro. If any
> checks within a test fail, the entire test is marked as failed.
> - Output Format: The output of the test program follows the TAP
> format. It includes a series of messages describing the test's status.
> For passed tests, it reports "ok," and for failed tests, it reports
> "not ok." Each test is numbered, e.g., "ok 1 - static initialization
> works," to indicate success or failure.
> - Check Functions: Several check functions are available, including
> check() for boolean conditions, check_int(), check_uint(), and
> check_char() for comparing values using various operators. check_str()
> is used to compare strings.
> - Skipping Tests: Tests can be skipped using test_skip() and can
> include a reason for skipping, which is printed as part of the report.
> - Diagnostic Messages: Tests can generate diagnostic messages using
> test_msg() to provide additional context or explanations for test
> failures.
> - Planned Failing Tests: Tests that are known to fail can be marked
> with TEST_TODO(). These tests will still run, and the failures will be
> reported, but they will not cause the entire suite to fail.
> - Building and Running: The unit tests can be built with "make
> unit-tests" (with some additional Makefile changes), and they can be
> executed manually or using a tool like prove.

Ok.

> Using the formerly given criteria, test-ctype.c is suitable for
> porting because it tests character type checks used extensively in
> Git. These tests cover various character types and their expected
> behaviour, ensuring the correctness and reliability of Git's
> operations, and test-ctype.c isolation makes it suitable for porting
> without relying on multiple libraries.

Ok.

> Here is a sample of the implementation of how I would write the unit
> test following the custom TAP framework taking t/helper/test-ctype.c
>
> - Create and rename the new .c file;
> I would rename it according to the convention done in the t/unit-test
> directory, by starting the name with a “t-” prefix e.g t-ctype.c
>
> - Document the tests and include the necessary headers:
> /**
>  *Tests the behavior of ctype
>  *functions
> */
> #include "test-lib.h"
> #include "ctype.h"
>
> - Define test functions:
> #define DIGIT "0123456789"
>
> static void t_digit_type(void)
> {
>     int i;
>     const char *digits = DIGIT;
>     for (i = 0; digits[i]; i++)
>    {
>          check_int(isdigit(digits[i]), ==, 0);
>    }

This tests that isdigit() returns 0 for each of the characters in
"0123456789", but first I think isdigit() should return 1, not 0 for
those characters.

And second, I think the test should check the value returned by
isdigit() for each of the 256 possible values of a char, not just for
the characters in "0123456789".

test-ctype.c is doing the right thing regarding those 2 issues.

> - Include main function which will call the test functions using the TEST macro;
> int main(void)
> {
>     TEST(t_digit_type(), "Character is a digit");
>     return test_done();
> }
>
> - Run the tests:
> ‘make && make’ unit-tests can be used build and run the unit tests
> Or run the test binaries directly:
> ./t/unit-tests/t-ctype.c
>
> The Makefile will be modified to add the file;
> UNIT_TEST_PROGRAMS += t-ctype
> The test output will be in the TAP format and will indicate which
> tests passed(ok) and which failed(not ok), along with diagnostic
> messages in case of failures.
>
> ok 1 - Character is a digit
>
> 1..1

Yeah, this looks right.

Thanks,
Christian.

Re: [RFC][Outreachy] Seeking Git Community Feedback on My Application

[Isoken Ibizugbe]

On Sat, Oct 28, 2023 at 9:07 AM Christian Couder
<christian.couder@gmail.com> wrote:
>
> On Wed, Oct 25, 2023 at 2:46 PM Isoken Ibizugbe <isokenjune@gmail.com> wrote:
>
> > Thank you for the review. I have made changes to the project plan and
> > it emphasizes the critical tasks of identifying, selecting, and
> > porting tests, making it more concise and aligned with the project's
> > scope.
>
> Good.
>
> > - Community Bonding (Oct 2 - Nov 20): Microproject contribution, Git
> > project application, get familiar with the Git codebase and testing
> > ecosystem.
> > -Identify and Select Tests: Identify and prioritize tests worth
> > porting, and document the selected tests. (I would classify tests that
> > are worth porting according to the following for now;
> >
> > Relevance: Prioritize tests that are relevant to the current Git codebase.
> > Coverage: Focus on tests that cover core functionality or critical code paths.
> > Usage Frequency: Port tests that are frequently used or run in Git's
> > development process.
> > Isolation: Choose tests that can be easily ported and run independently.
>
> I think the main issue with identification is that now in t/helper/ we
> have both:
>
>   1) code that implements helpers that are used by the end-to-end
> tests scripts written in shell and named "t/tXXXX-*.sh" where XXXX is
> a number, and
>   2) code that implements unit tests for some C code in the code base.
>
> So I think only 2) should be ported to the unit test framework, and 1)
> should not be ported and stay in t/helper/.
>
> > - Write Unit Tests: Write unit tests for the identified test cases
> > using the Git custom test framework.
> > - Port Existing Tests: Port selected test cases from the t/helper
> > directory to the unit testing framework, by modifying them to work
> > within the custom TAP framework.
> > - Test Execution and Debugging: Execute the newly written unit tests
> > and the ported tests using the test framework.
> > - Seek Feedback: Share the progress with mentors and the Git
> > community, and address any concerns or suggestions provided by the
> > community.
> > - Documentation and Reporting: Document the entire process of
> > migrating Git's tests to the unit testing framework, and prepare a
> > final project report summarizing the work done, challenges faced, and
> > lessons learned.
> >
> > What is the custom TAP framework?
> >
> > According to this patch
> > (https://lore.kernel.org/git/ca284c575ece0aee7149641d5fb1977ccd7e7873.1692229626.git.steadmon@google.com/)
> > by Phillip Wood, which contains an example implementation for writing
> > unit tests with TAP output. The custom TAP framework is a Test
> > Anything Protocol (TAP) framework that allows for clear reporting of
> > test results, aiding in debugging and troubleshooting.
>
> Ok. Our end-to-end tests scripts written in shell already use TAP,
> that's why it's nice to have unit tests also using TAP.
>
> > The framework contains the following features:
> >
> > - Test Structure: Unit tests are defined as functions containing
> > multiple checks. The tests are run using the TEST() macro. If any
> > checks within a test fail, the entire test is marked as failed.
> > - Output Format: The output of the test program follows the TAP
> > format. It includes a series of messages describing the test's status.
> > For passed tests, it reports "ok," and for failed tests, it reports
> > "not ok." Each test is numbered, e.g., "ok 1 - static initialization
> > works," to indicate success or failure.
> > - Check Functions: Several check functions are available, including
> > check() for boolean conditions, check_int(), check_uint(), and
> > check_char() for comparing values using various operators. check_str()
> > is used to compare strings.
> > - Skipping Tests: Tests can be skipped using test_skip() and can
> > include a reason for skipping, which is printed as part of the report.
> > - Diagnostic Messages: Tests can generate diagnostic messages using
> > test_msg() to provide additional context or explanations for test
> > failures.
> > - Planned Failing Tests: Tests that are known to fail can be marked
> > with TEST_TODO(). These tests will still run, and the failures will be
> > reported, but they will not cause the entire suite to fail.
> > - Building and Running: The unit tests can be built with "make
> > unit-tests" (with some additional Makefile changes), and they can be
> > executed manually or using a tool like prove.
>
> Ok.
>
> > Using the formerly given criteria, test-ctype.c is suitable for
> > porting because it tests character type checks used extensively in
> > Git. These tests cover various character types and their expected
> > behaviour, ensuring the correctness and reliability of Git's
> > operations, and test-ctype.c isolation makes it suitable for porting
> > without relying on multiple libraries.
>
> Ok.
>
> > Here is a sample of the implementation of how I would write the unit
> > test following the custom TAP framework taking t/helper/test-ctype.c
> >
> > - Create and rename the new .c file;
> > I would rename it according to the convention done in the t/unit-test
> > directory, by starting the name with a “t-” prefix e.g t-ctype.c
> >
> > - Document the tests and include the necessary headers:
> > /**
> >  *Tests the behavior of ctype
> >  *functions
> > */
> > #include "test-lib.h"
> > #include "ctype.h"
> >
> > - Define test functions:
> > #define DIGIT "0123456789"
> >
> > static void t_digit_type(void)
> > {
> >     int i;
> >     const char *digits = DIGIT;
> >     for (i = 0; digits[i]; i++)
> >    {
> >          check_int(isdigit(digits[i]), ==, 0);
> >    }
>
> This tests that isdigit() returns 0 for each of the characters in
> "0123456789", but first I think isdigit() should return 1, not 0 for
> those characters.

yes, that is true. should I send a re-roll?
>
> And second, I think the test should check the value returned by
> isdigit() for each of the 256 possible values of a char, not just for
> the characters in "0123456789".
>
> test-ctype.c is doing the right thing regarding those 2 issues.
>
> > - Include main function which will call the test functions using the TEST macro;
> > int main(void)
> > {
> >     TEST(t_digit_type(), "Character is a digit");
> >     return test_done();
> > }
> >
> > - Run the tests:
> > ‘make && make’ unit-tests can be used build and run the unit tests
> > Or run the test binaries directly:
> > ./t/unit-tests/t-ctype.c
> >
> > The Makefile will be modified to add the file;
> > UNIT_TEST_PROGRAMS += t-ctype
> > The test output will be in the TAP format and will indicate which
> > tests passed(ok) and which failed(not ok), along with diagnostic
> > messages in case of failures.
> >
> > ok 1 - Character is a digit
> >
> > 1..1
>
> Yeah, this looks right.
>
> Thanks,
> Christian.

Re: [RFC][Outreachy] Seeking Git Community Feedback on My Application

[Christian Couder]

On Sat, Oct 28, 2023 at 12:41 PM Isoken Ibizugbe <isokenjune@gmail.com> wrote:
>
> On Sat, Oct 28, 2023 at 9:07 AM Christian Couder
> <christian.couder@gmail.com> wrote:

> > > #define DIGIT "0123456789"
> > >
> > > static void t_digit_type(void)
> > > {
> > >     int i;
> > >     const char *digits = DIGIT;
> > >     for (i = 0; digits[i]; i++)
> > >    {
> > >          check_int(isdigit(digits[i]), ==, 0);
> > >    }
> >
> > This tests that isdigit() returns 0 for each of the characters in
> > "0123456789", but first I think isdigit() should return 1, not 0 for
> > those characters.
>
> yes, that is true. should I send a re-roll?

Yes, please.

Re: [RFC][Outreachy] Seeking Git Community Feedback on My Application

[Isoken Ibizugbe]

On Sat, Oct 28, 2023 at 1:38 PM Christian Couder
<christian.couder@gmail.com> wrote:
>
> On Sat, Oct 28, 2023 at 12:41 PM Isoken Ibizugbe <isokenjune@gmail.com> wrote:
> >
> > On Sat, Oct 28, 2023 at 9:07 AM Christian Couder
> > <christian.couder@gmail.com> wrote:
>
> > > > #define DIGIT "0123456789"
> > > >
> > > > static void t_digit_type(void)
> > > > {
> > > >     int i;
> > > >     const char *digits = DIGIT;
> > > >     for (i = 0; digits[i]; i++)
> > > >    {
> > > >          check_int(isdigit(digits[i]), ==, 0);
> > > >    }
> > >
> > > This tests that isdigit() returns 0 for each of the characters in
> > > "0123456789", but first I think isdigit() should return 1, not 0 for
> > > those characters.
> >
> > yes, that is true. should I send a re-roll?
>
> Yes, please.

#include "test-lib.h"
#include "ctype.h"

static void t_digit_type(void)
{
    int i;

for (i = 0; i < 256; i++)
        {
            if (i < '0' || i > '9')
                check_int(isdigit(i), ==, 0);
            else
                check_int(isdigit(i), ==, 1);
        }
}

int main(void)
{
    TEST(t_digit_type(), "Character is a digit");
    return test_done();
}

Re: [RFC][Outreachy] Seeking Git Community Feedback on My Application

[Phillip Wood]

Hi Isoken

On 28/10/2023 15:07, Isoken Ibizugbe wrote:
> #include "test-lib.h"
> #include "ctype.h"
> 
> static void t_digit_type(void)
> {
>      int i;
> 
> for (i = 0; i < 256; i++)
>          {
>              if (i < '0' || i > '9')
>                  check_int(isdigit(i), ==, 0);
>              else
>                  check_int(isdigit(i), ==, 1);
>          }
> }

I think this is correct but when you are writing tests it is important 
to think about how easy they will be to debug if they fail. In this case 
because there is a single test to check all the characters it will be 
hard to tell which character caused the test to fail. If we restructure 
the code to use a separate test for each character then we will be able 
to see which characters are causing isdigit() to fail. To do that we 
need a function that prints the character that we're testing. Because we 
don't want to print raw control characters in the test name we need to 
check if the character can be printed as is or if it needs to be printed 
as an octal escape sequence. We can do that by writing a function like

static const char* char_name(int i)
{
	static char buf[5];
	if (i < ' ' || i >= 127)
		xsnprintf(buf, sizeof(buf), "\\%03o", (unsigned int)i);
	else
		xsnprintf(buf, sizeof(buf), "%c", i);

	return buf;
}

Then we can write a test function defines a separate test for each character

static void t_isdigit(void)
{
	for (int i = 0; i < 256; i++) {
		if (i < '0' || i > '9')
			TEST(check(!isdigit(i)), "'%s' is not a digit",
			     char_name(i));
		else
			TEST(check(isdigit(i)), "'%s' is a digit",
			     char_name(i));
	}
}

Note that as isdigit() returns a boolean we simplify things by using 
check() rather than check_int().

Now we can easily see which character is being tested when a check fails 
as the character being tested is in the test name. You would call this 
function with

int cmd_main(int argc, const char** argv)
{
	t_isdigit();
	return test_done();
}

I think it would be helpful for you to try and build and run this test 
by checking out the unit test branch from Junio's tree[1] and adding 
this test. You could then try making the test fail to see what the 
output for a failing test looks like.

Best Wishes

Phillip

[1] You can fetch that branch with
         git fetch https://github.com/gitster/git.git 
js/doc-unit-tests-with-cmake
     and then create your branch with
         git checkout -b isdigit-unit-tests FETCH_HEAD