[OUTREACHY] Final Application For Git Internshhip

[OUTREACHY] Final Application For Git Internshhip

[Naomi Ibe]

I'm Ibe Naomi Amarachi,I'm a Nigerian and I currently live in
Lagos,Nigeria. I'm a graduate of the African Leadership Xcelerator
Software Engineering program (ALX SE), with specialization in backend
web development and I'm applying for the "Moving Existing Tests to a
Unit Testing Framework" project

Some of my projects that involve working with Shell,C and Git can be found here:

https://github.com/Amarajah/alx-system_engineering-devops

https://github.com/Amarajah/alx-low_level_programming

Git has been a part of my software engineering journey from day one
and it's allowed me to collaborate with peers and also keep track of
my personal projects. Currently Git uses end-to-end tests for error
conditions that could easily be captured by unit tests, the project is
aimed at turning end-to-end tests to unit tests, and I'd love to be a
part of it

My microproject contribution is here:

https://public-inbox.org/git/20231009011652.1791-1-naomi.ibeh69@gmail.com/T/#u

And here is my updated contribution link after review by the Git community:

https://public-inbox.org/git/xmqqttqox5cp.fsf@gitster.g/T/#u

Below is my project timeline:
(Of course I'd be very much willing to work with the community and
mentors to edit it so it perfectly meets up to the community's
expectations)

October 2, 2023 - October 30, 2023

Familiarizing myself with the community , mailing list and
contributing my microproject

November 20, 2023 - December 4, 2023

Familiarizing myself with the already existing tests and also the
chosen unit test framework

Do more research on the internship projects and find better ways to
get it done in harmony with coding guidelines and community
requirements

December 4, 2023 - December 31, 2023

First document the initial state of the test files, then make sure all
test files conform to coding guidelines down to the tiniest details
(e.g git/t/helper/test-write-cache.c and git/t/helper/test-advise.c
have die() messages which do not conform to coding guidelines)

January 2, 2024 - January 31, 2024

Run the tests and verify they still work as originally intended

Begin migrations of test files

Test migrated files and make necessary changes based on feedback
received from teammates and mentors

February 1, 2024 - March 1, 2024

Continue testing migrated files and making necessary changes based on
feedback received from teammates and mentors

Document each step and request for reviews from teammates and mentors

Tidy up the project,make sure all necessary files are migrated, they
all work as intended, they are well documented and that there are no
conflicts

Re: [OUTREACHY] Final Application For Git Internshhip

[Christian Couder]

On Tue, Oct 24, 2023 at 9:48 AM Naomi Ibe <naomi.ibeh69@gmail.com> wrote:
>
> I'm Ibe Naomi Amarachi,I'm a Nigerian and I currently live in
> Lagos,Nigeria. I'm a graduate of the African Leadership Xcelerator
> Software Engineering program (ALX SE), with specialization in backend
> web development and I'm applying for the "Moving Existing Tests to a
> Unit Testing Framework" project
>
> Some of my projects that involve working with Shell,C and Git can be found here:
>
> https://github.com/Amarajah/alx-system_engineering-devops
>
> https://github.com/Amarajah/alx-low_level_programming
>
> Git has been a part of my software engineering journey from day one
> and it's allowed me to collaborate with peers and also keep track of
> my personal projects. Currently Git uses end-to-end tests for error
> conditions that could easily be captured by unit tests, the project is
> aimed at turning end-to-end tests to unit tests, and I'd love to be a
> part of it

Maybe a period is missing at the end of the above sentence. Otherwise Ok.

> My microproject contribution is here:
>
> https://public-inbox.org/git/20231009011652.1791-1-naomi.ibeh69@gmail.com/T/#u
>
> And here is my updated contribution link after review by the Git community:
>
> https://public-inbox.org/git/xmqqttqox5cp.fsf@gitster.g/T/#u

It could help to say if your contribution has been merged to 'master',
'next', 'seen' or not at all.

> Below is my project timeline:
> (Of course I'd be very much willing to work with the community and
> mentors to edit it so it perfectly meets up to the community's
> expectations)
>
> October 2, 2023 - October 30, 2023
>
> Familiarizing myself with the community , mailing list and
> contributing my microproject
>
> November 20, 2023 - December 4, 2023
>
> Familiarizing myself with the already existing tests and also the
> chosen unit test framework
>
> Do more research on the internship projects and find better ways to
> get it done in harmony with coding guidelines and community
> requirements
>
> December 4, 2023 - December 31, 2023
>
> First document the initial state of the test files, then make sure all
> test files conform to coding guidelines down to the tiniest details
> (e.g git/t/helper/test-write-cache.c and git/t/helper/test-advise.c
> have die() messages which do not conform to coding guidelines)

We don't advise spending a lot of time during your internship with
small things that could be part of someone else's microproject later.
You should be focused on the internship goal first.

Of course if you are migrating some code to the new unit test
framework, it's Ok to improve that code before migrating it. But no
need to improve everything under t/helper before starting to migrate
parts of the code there.

I think that one of the important tasks to be done early is to
identify what code in t/helper is unit testing C code and what code is
really about helping other tests in the t/t*.sh scripts. It would be
nice if you could give an example of each kind of code.

> January 2, 2024 - January 31, 2024
>
> Run the tests and verify they still work as originally intended
>
> Begin migrations of test files
>
> Test migrated files and make necessary changes based on feedback
> received from teammates and mentors

An example of how you would migrate parts of a test, or how a migrated
test would look like, would be nice.

> February 1, 2024 - March 1, 2024
>
> Continue testing migrated files and making necessary changes based on
> feedback received from teammates and mentors
>
> Document each step and request for reviews from teammates and mentors
>
> Tidy up the project,make sure all necessary files are migrated, they
> all work as intended, they are well documented and that there are no
> conflicts

Thanks,
Christian.

Re: [OUTREACHY] Final Application For Git Internshhip

[Christian Couder]

On Wed, Oct 25, 2023 at 2:14 PM Naomi Ibe <naomi.ibeh69@gmail.com> wrote:
>>
>> It could help to say if your contribution has been merged to 'master',
>> 'next', 'seen' or not at all.
>
>  My microproject contribution has been scheduled to be merged to the master branch.

Great, please add this information to your application.

>> I think that one of the important tasks to be done early is to
>> identify what code in t/helper is unit testing C code and what code is
>> really about helping other tests in the t/t*.sh scripts. It would be
>> nice if you could give an example of each kind of code.
>
> In my opinion, helper/test-ctype.c is a unit test file containing a set of unit tests for character classification functions,

Right.

> while helper/test-dir-iterator.c is a unit test file which works together with the t/t0066-dir-iterator.sh file to iterate through a directory and give details on its contents. It likely is used for testing and inspecting directory structures and file types within a specified path.

Actually "t/helper/test-dir-iterator.c" and "t/t0066-dir-iterator.sh"
are used together to test the code in "dir-iterator.h" and
"dir-iterator.c", so it's kind of special. Ideally this could be
ported to the unit test framework as the goal is to test quite low
level code (instead of a full git command for example), but I am not
sure how easy it would be, and if it would even be worth it.

>> An example of how you would migrate parts of a test, or how a migrated
>> test would look like, would be nice.
>
> I'd first create a new test file, then include "test-libtap/tap.h" and "test-tool.h" header files, then I would initialize TAP with this command plan_tests(x), where x defines the number of tests to be run inside that file.
> Below the plan_tests();, I'd migrate and edit my specific test function and requirements, and after that, I'd add my "done_testing();" and then "return exit_status();"

These are quite good guidelines, but not quite an example.

Thanks,
Christian.

Re: [OUTREACHY] Final Application For Git Internshhip

[Naomi Ibe]

On Sat, Oct 28, 2023 at 9:25 AM Christian Couder
<christian.couder@gmail.com> wrote:
>
> On Wed, Oct 25, 2023 at 2:14 PM Naomi Ibe <naomi.ibeh69@gmail.com> wrote:
> >>
> >> It could help to say if your contribution has been merged to 'master',
> >> 'next', 'seen' or not at all.
> >
> >  My microproject contribution has been scheduled to be merged to the master branch.
>
> Great, please add this information to your application.
>
> >> I think that one of the important tasks to be done early is to
> >> identify what code in t/helper is unit testing C code and what code is
> >> really about helping other tests in the t/t*.sh scripts. It would be
> >> nice if you could give an example of each kind of code.
> >
> > In my opinion, helper/test-ctype.c is a unit test file containing a set of unit tests for character classification functions,
>
> Right.
>
> > while helper/test-dir-iterator.c is a unit test file which works together with the t/t0066-dir-iterator.sh file to iterate through a directory and give details on its contents. It likely is used for testing and inspecting directory structures and file types within a specified path.
>
> Actually "t/helper/test-dir-iterator.c" and "t/t0066-dir-iterator.sh"
> are used together to test the code in "dir-iterator.h" and
> "dir-iterator.c", so it's kind of special. Ideally this could be
> ported to the unit test framework as the goal is to test quite low
> level code (instead of a full git command for example), but I am not
> sure how easy it would be, and if it would even be worth it.
>
> >> An example of how you would migrate parts of a test, or how a migrated
> >> test would look like, would be nice.
> >
> > I'd first create a new test file, then include "test-libtap/tap.h" and "test-tool.h" header files, then I would initialize TAP with this command plan_tests(x), where x defines the number of tests to be run inside that file.
> > Below the plan_tests();, I'd migrate and edit my specific test function and requirements, and after that, I'd add my "done_testing();" and then "return exit_status();"
>
> These are quite good guidelines, but not quite an example.
>

Using the test-ctype.c file as an example, the migrated unit test file
would look like this:

#include "test-tool.h"
#include "test-libtap/tap.h"
#include <stdio.h>
#include <string.h>

static int is_in(const char *s, int ch) {
    if (ch == '\0')
        return ch == *s;
    if (*s == '\0')
        s++;
    return !!strchr(s, ch);
}

int main() {
    // Init TAP with the number of planned tests (1 test per character class)
    plan(12);

    // Character classes
    char *classes[] = {
        "DIGIT", " \n\r\t",
"abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ",
        "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789",
        "*?[\\", "$()*+.?[\\^{|", "!\"#%&',-/:;<=>@_`~",
        "\x00\x01\x02\x03\x04\x05\x06\x07\x08\x09\x0a\x0b\x0c\x0d\x0e\x0f"
        "\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x1a\x1b\x1c\x1d\x1e\x1f"
        "\x20\x21\x22\x23\x24\x25\x26\x27\x28\x29\x2a\x2b\x2c\x2d\x2e\x2f"
        "\x30\x31\x32\x33\x34\x35\x36\x37\x38\x39\x3a\x3b\x3c\x3d\x3e\x3f"
        "\x40\x41\x42\x43\x44\x45\x46\x47\x48\x49\x4a\x4b\x4c\x4d\x4e\x4f"
        "\x50\x51\x52\x53\x54\x55\x56\x57\x58\x59\x5a\x5b\x5c\x5d\x5e\x5f"
        "\x60\x61\x62\x63\x64\x65\x66\x67\x68\x69\x6a\x6b\x6c\x6d\x6e\x6f"
        "\x70\x71\x72\x73\x74\x75\x76\x77\x78\x79\x7a\x7b\x7c\x7d\x7e\x7f",
    };

    // Test each character class
    for (int i = 0; i < 12; i++) {
        char description[50];
        sprintf(description, "Testing %s character class", classes[i]);
        for (int ch = 0; ch < 256; ch++) {
            int result = is_in(classes[i], ch);
            if (ch == EOF)
                ok(result == is_in(classes[i], ch), description);
            else
                is_int(result, is_in(classes[i], ch), description);
        }
    }

    // After testing all
    done_testing();

    return exit_status();
}


> Thanks,
> Christian.