On Sat, Oct 28, 2023 at 9:07 AM Christian Couder
[off-list ref] wrote:

On Wed, Oct 25, 2023 at 2:46 PM Isoken Ibizugbe [off-list ref] wrote:

quoted

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.

quoted

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

quoted

- 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/ (local))
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.

quoted

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.

quoted

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.

quoted

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.

quoted

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