On Sat, Oct 28, 2023 at 9:07 AM Christian Couder <christian.couder@xxxxxxxxx> wrote: > > On Wed, Oct 25, 2023 at 2:46 PM Isoken Ibizugbe <isokenjune@xxxxxxxxx> 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@xxxxxxxxxx/) > > 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.
