feat: add tests and CI/CD workflow

[msimerson]

• Add GitHub Actions workflow for testing on macOS (BSD-like)
• Add regression test for key matching (repro_match.c)
• Add unit tests for core functions
• Update makefile with test targets
• Fix typos in readme.md

[msimerson]

If you click on the All checks have passed and open it, you can click on Test / test to see the test results. Of course, you can always check out the branch and run it locally, but this is completely automated.

[JohnKaul]

I am trying to read more up on GitHub and brushing up on my git usage so, I have cherry-picked a file from this branch. It looks like the test.yml preformed great.

1. pulled your branch locally.
2. cherry-picked a file (test.yml)
3. modified test.yml slightly
4. added you as author in my commit msg.
   (I also added my name as "modified" because I didn't want to say you
   did something you didn't do in case something didn't work. I only
   modified the yml to run the test_sysconf binary after building.)

Commands:

git checkout -b msimerson-feat/test-infrastructure main
git checkout main
git checkout msimerson-feat/test-infrastructure -- .github/workflows/test.yml
...

That's enough reading/learning "github stuff", for tonight, for me. Test went great though. :)

[msimerson]

Test went great though. :)

I've got GitHub Actions set up in over 100 repos. It's taken a while but I'm pretty good at it.

Combined with a robust test suite, it provides a very reliable gate against PRs that break functionality.

[JohnKaul]

That's great! As I imagine you would be after that many yml file creations. :D But, being good at something shows you enjoy it. I'm glad you're good/enjoy it.

I view this type of stuff (GitHub: repo config, merging, reviews, etc) in a same spirit as office paperwork or editor configuration. Sometimes I enjoy setting up my editor but not all the time; most times I just want to code. ...I half regret pushing to GitHub because I don't enjoy this aspect (especially for a project that only 4 people--a proj with 4 stars--like).

Also, not directly (more "sort of") related but I see you modified the makefile in your PR to compile the test_sysconf binary to the test directory. I'm developing on a Mac which uses GNU make by default (if I were using *BSD my compiler would be BSD, of course). You can create another makefile to override the projects settings based on the version of make you're using. To give you an example: I have a makefile (not commited to the repo) called: "GNUmakefile" in which I add my own stuff.

I'll show an example that:

1. Creates a target ("check") which allows me to run make check that just runs the tests.
2. Creates an override for the build target which compiles in sanitizer support and runs a syntax test when I type make.

GNUmakefile (your instance may differ):

# include the regular makefile
include ./makefile

.PHONY: check
check: test
	CHECKS='Testing sysconf...'
		@./test_sysconf
	CHECKS='Testing syntax...'
		@./test_syntax.sh

CFLAGS		:=	-fno-exceptions -pipe -Wall -W -g -fsanitize=address,undefined
sysconf: almostclean 
	sysconf_TARGET='sysconf'
		$(CC) $(CFLAGS) -o sysconf $(SOURCES)
		@echo "---[ TESTING ]---------------------------------------------------"
		@./test_syntax.sh

Doing this would allow you to establish settings you prefer/need--and not push those settings upon the project for example. That is to say, I think of the "makefile" as a thing for my future self to "compile, setup, and install a thing" and I keep a "GNUmakefile" for my "development self" (I separate 'developing' and 'compiling/using' into different categories). I hope that make sense.

Anyways, at work (again) so I better get back to it. l8r

[JohnKaul]

...I just realized that the above comment about 'GNUmakefile' could be construed as me saying that's the way you should do something but that's not why I mentioned it (sorry, don't take it that way please). I only mention that tip to hopefully offer up a helpful tip for you and your development process if it could be applied.