On Wed, Oct 25, 2023 at 2:14 PM Naomi Ibe <naomi.ibeh69@xxxxxxxxx> 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.
