Unit test tooling in Hamlib
Maintainers usually reply within 1 day
@mikaelnousiainen is already working on this.
Since Feb 27, 2026.
Assessment
This issue has not been assessed yet.
Description
As a part of the ARDC improvement project tasks (for example task #1940), I'd very much like to start writing unit tests to verify the new application logic and features work as expected. This kind of test code is tightly-coupled with the Hamlib C (or potentially C++ API bindings) code, so it's beneficial that it is written in the same language as the original code, as it will be calling the public API functions of Hamlib directly.
Currently, the only test code that Hamlib codebase contains, are the simulators (which are more in the category of integration or system testing) and some Python test code that primarily tests the Python bindings (again, more for integration/system testing I'd argue).
In order to help writing unit tests, I'd propose we use some simple unit testing framework that supports both C and C++ testing to get the following benefits:
- clear structure for declaring and grouping tests
- standardized test assertions
- standardized way to run tests
- test result reporting (success / failure with error messages)
- integration with autotools (current build framework) -> automake uses TAP protocol
- integration with CI (GitHub Actions) -> GHA uses JUnit reporting for test results
One possible choice is to go with a very simple, single-header library, such as Acutest: https://github.com/mity/acutest
Please see the GitHub README of Acutest for examples on assertions and how tests are declared - it uses simple C macros for most things (just like many other C/C++ unit test frameworks I've seen), but is otherwise very "unintrusive" as it's just a single header file we can include in the sources. Additionally, it includes simple support for both TAP and JUnit reporting. Both C and C++ are supported.
Other suggestions are welcome!
- Dominant language
- C
- Stars
- 851
- Forks
- 308
- Avg merge
- 2d 21h
- Merged PRs (30d)
- 9
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from Hamlib/Hamlib
-
Difficulty 2/5 1-3 hours Newbie friendliness 63/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 90/100
Hamlib/Hamlib#2149 · 5 comments ·
Maintainers usually reply within 1 day
-
G90: add RIT setting support; negative RIT readback is ambiguousPossibly taken A pull request linked to this issue is open or already merged. Open
Difficulty 3/5 1-2 days Newbie friendliness 55/100
Maintainers usually reply within 1 day
-
G90 AF gain readback encoding anomaly on v1.8 with full range hardware evidencePossibly taken A pull request linked to this issue is open or already merged. OpenBug
Difficulty 4/5 3-5 days Newbie friendliness 48/100
Hamlib/Hamlib#2245 · 2 comments ·
Maintainers usually reply within 1 day
Similar issues
-
type: feature
Difficulty 1/5 Under an hour Newbie friendliness 77/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
FujiNetWIFI/fujinet-firmware#1932 ·
Maintainers usually reply within 1 day
-
stdlib
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
[LOGO] kairo linuxOpenlogo request
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
fastfetch-cli/fastfetch#2650 ·
Maintainers usually reply within 1 day
-
research-radar
Difficulty 2/5 1-3 hours Newbie friendliness 63/100
Maintainers usually reply within 1 day