Add unit-test framework for L3 interfaces and functionality [?]

[gapisback]

HI, @gregthelaw -- While working on improving the capability of l3_dump.py, I discovered a few limitations and opened issue #12 .

I want to suggest a few improvements, based on my explorations to resolve this issue:

1. Add a separate unit-testing framework. The idea is that we build stand-alone unit-test programs each exercising a capability and which actually verify that the whole tooling does what it's intended to do. (See below for a prototype.)
2. If we do add one, the dirs will be named tests/unit, under which unit-test sources will live.
3. Rename existing test-use-cases/ to be simply use-cases and adjust the Makefile accordingly. I see the programs in this set really to be example use-case programs, so naming them test-use-cases/ is a bit misleading. (And will be confusing with proposed tests/unit sub-dir for unit-tests. I should have foreseen this name-clash earlier when I created the test-use-cases/ sub-dir.)

I did some evaluation in my head on this proposal, and would like to run it by you before charging down with a PR to bring-in unit-tests sources & files:

Pros:

• Makes the l3 library robust and dependable as it matures. (Things like issue Logic in l3_dump.py is buggy and incomplete. Does not handle large #s of trace records and EOF cleanly. #12 won't recur.)
• As we integrate more with LOC and its variants, this framework will provide robust testability that all the LOC-unpacking is, indeed, working as expected [ at least for simple unit-test cases ].

Cons:

• Additional maintenance of unit-test sources including, especially, Makefile updates.
• We will further need something like pytest exerciser to actually run these unit-tests and exercise the l3_dump.py on generated L3 log-dumps and to verify that the stuff works as designed. (I don't have the pytest prototyped now, but that would be the way to go if we went down this path.)

Prototype

Here is what I have by way of a prototype of this unit-testing dev effort:

agurajada-Linux-Vm:[131] $ ll tests/unit
total 12
-rw-rw-r-- 1 agurajada  899 Mar 28 05:32 l3_dump.py-test.c

Right now, it's a very simple program generating 4 log-entries. I used this program (and this unit-test exercise) to flesh-out and log the bugs reported in issue #12 .

Associated Makefile changes can be seen in my dev-branch which I just pushed to Github. I have a draft PR #13, which shows you an idea how the files will change.

Let's discuss first if this approach seems reasonable to you. If yes, this work, which involves Makefile re-factoring, will be broken-up into smaller pieces for integration to the repo.

[gregthelaw]

Yes, some automated regression testing like you propose is highly desirable. I am supportive!

I don't know much about what frameworks are available -- at Undo it's mostly home-grown although we are slowly moving to pytest. But any testing is better than no testing!

I've seen people hook up travis CI to github -- that or some alternative would be cool, but I don't know how much work that would be.

[gapisback]

Great! Glad you agree, @gregthelaw .

I cleaned-up change set in PR #13 and it's now in review with you. This adds basic dir-struct and one unit-test file.

Once this lands, I will find some time to add pytest tests around these unit-tests, to properly exercise and verify the functioning of l3_dump.py.

[gapisback]

This infrastructure has been developed and integrated into /main under:

e1a79a1 Aditya P. Gurajada 8 days ago Tue, 02-Apr-2024, 12:49:02 PM (Authored: Wed, 27-Mar-2024, 04:18:36 PM)
 [Test] Makefile rules to build and run unit-tests for l3_dump.py to deal with eof

Moving on ...