Re: Fwd: [GSOC][Proposal] Move existing tests to a unit testing framework

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello,

Thank you for the review and sorry for the late reply.
I have made the required changes in the document and uploaded the pdf
to GSOC webpage

Thank You,
Sanchit Jindal

----------------------------------------------------------------------------------------------------
Google Summer Of Code Proposal
Git (Move existing tests to a unit testing framework)

Personal Information
Name:          Sanchit Jindal
Email:           sanchit1053@xxxxxxxxx
Qualification: B.Tech in Computer Science and Engineering

Greetings,

My name is Sanchit Jindal, currently pursuing my B.E. in Computer
Science at the Indian Institute of Technology, Bombay, I will complete
my degree in May 2024. I am writing to put forward my proposal for the
Git Project to transition the unit tests to the new Unit Testing
Framework.


Throughout my academic journey and internships, I've gained valuable
experience across diverse domains, ranging from machine learning to
fundamental system components like compilers and operating systems.
This breadth of exposure has honed my ability to swiftly grasp new
concepts and adapt to different codebases. Proficient in both C, C++
and shell scripting, I am well-equipped to contribute effectively to
the project.


In my internship at Quadeye last summer I worked on building an
efficient and user-friendly library for creating and maintaining
network connections. The project included building a layered
architecture with a modular approach, and C++ meta programming for
easy transfer of any structure between nodes.

I have also worked on an gdb extension to provide a front end to
display graphical structures in the program via a web application. The
program aids in debugging pointer structures and to visualise the
run-time of the code.

For this GSOC project, I aspire to make meaningful contributions to
the open-source community. My interest in software development drives
me to create solutions that will offer utility to others.

## Overview

### Proposed Abstract

Git has a lot of test cases that need to be migrated to use a new unit
testing framework. This typically involves moving code from both:
- a “t/helper/test-*.c” test helper in C, and
- a “t/*.sh” test script in shell that invokes the test helper

over to a single “t/unit-tests/t-*.c” in C using the unit testing framework.

### Details

The Project entails porting the current testing framework (which is a
collection of helper files written in c that provide various
utilities, and various shell scripts) to using a new Unit-Testing
Library. The shell scripts in the original code base setup the
environment and , using the helper functions, test the functionalities
provided by Git. The new framework utilises the test-lib library that
will combine the functionality of both the helper functions and the
shell scripts into one unit-test.
Advantages of this approach
- Unit Tests are a great way to check any program and to test all
possible corner cases and functions
- Using this new testing framework will provide a more modular
approach to unit testing, allowing to create more extensive tests, and
to provide more fine-grained tests when required.
- Having a testing library also provides various other features such
as better debug messages or a better CLI to choose and run tests.
- The tests will also improve the runtime as instead of running
multiple process (with each use of shell commands), the program can
compile and run a single process
- The approach will also future proof the unit testing as having a c
library will provide a better base than shell scripts to test
libraries and other internal features


### Basic Structure of the Changes

For each file in the helper directory I will create a corresponding
unit-test file. (Some files which are being used by multiple tests and
implement more general functionality may not be ported to the new
library)
Each test in the script will be corresponding to a function that will
be called in the format

`TEST(funtion_name(), “SUCCESS MESSAGE”);`

The function body will contain the main implementation of the test
corresponding to the c file ( The helper function will ideally be the
same with no or minimal changes just to allow it to be called as
required )
Where the assert usually given at the end of the test will be made
using the utility functions such as check_int, check_str and others,
(or creating more function as they are required)
The Make files will be updated to remove the use of shell script with
compiling and running the new c programs



### Previous Contributions

I have worked on the micro-project
Use test_path_is_* functions in test scripts
Thread Link: https://lore.kernel.org/git/b8d0620d4104106210ecf6a34ada591adf01cff8.1711049963.git.gitgitgadget@xxxxxxxxx/

Status: Open
I had some difficulties in understanding the usage of gitgitGadget and
git send-email which are being employed as the Pull request
alternatives. Having tried gitgitGadget I am confident that I will be
able to utilise it hereafter. I am having some trouble using git
send-email with the network at my institute but I am optimistic that I
will be able to use it after the completion of my degree.

With the guidance of Eric Sunshine and Junio C Hamano, I have iterated
through different versions of the pull request, and familiarised
myself with the git commit pattern and formalities


### Deliverables

The plan is to port the helper functions from helper directory to the
unit-test directory along with the test defined in the shell scripts.
Some of the helper tools which have a more basic functionality and are
being used by multiple test scripts can be left untouched.
As a stretch goal I will try to port the shell scripts to the new
testing interface creating new functions for the library as required
I also plan to keep documenting all the changes made and to keep in
constant contact with the mentors regarding any bugs or reviews
regarding the code.


### Availability

I am expecting to be free from my academic responsibilities by 4th
May. I have no further commitments for the summer and will be able to
provide about 40-50 hours of work per week. I will try porting at
least one file per week, depending on the community feedback and the
pace of the development process.

### Related Work

The project has been worked on by Achu Luma for the Outreachy Internship
Test-ctype:
https://lore.kernel.org/git/20240112102743.1440-1-ach.lumap@xxxxxxxxx/#t
Test-advise:
https://lore.kernel.org/git/20240112102122.1422-1-ach.lumap@xxxxxxxxx/
Test-data:
https://lore.kernel.org/git/20240205162506.1835-2-ach.lumap@xxxxxxxxx/
Test-hash:
https://lore.kernel.org/git/20240229054004.3807-2-ach.lumap@xxxxxxxxx/
Test-strcmp-offset:
https://lore.kernel.org/git/20240310144819.4379-1-ach.lumap@xxxxxxxxx/

Another testcase has also been handled by Ghanshyam Thakkar
Test–oid-array:
https://lore.kernel.org/git/20240223193257.9222-1-shyamthakkar001@xxxxxxxxx/


### Timeline (Tentative)

Community Bonding
(1 May- 26 May)
Be in contact with mentors and figure out the best way to migrate the
test-cases, Familiarise myself with the library and previous work done
during the outreachy program.

Phase I
(27 May - 11 July)
Begin tackling the harder or longer testcases that will require more
knowledge of the implementation

Phase II
(12 July - 18 Aug)
Keep working on the testcases following the mentors and community feedback

Final Week
(19 Aug - 26 Aug)
Finish up the remaining testcases, fixing any bugs that may be
discovered in the earlier implementations


### Acknowledgement

I would like to thank Eric Sunshine and Junio C Hamano for helping me
with the microproject and for the guidance on the gitgitGadget and git
send-email features, And also helping me get acquainted with the git
PR guidelines.

Regards
Sanchit Jindal





[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux