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

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