Strategy and Implementation: Establish Test Suite and CI Validation

[kivra-pauoli]

Description

Currently, test coverage is virtually non-existent. As we move past the initial version, we need a robust testing strategy to prevent regressions and validate new features before they reach users.

This issue tracks the decision-making process for our testing architecture and the subsequent implementation of the chosen framework.

Proposed Testing Approaches

We need to evaluate and decide between (or combine) the following:

• In-repo Unit/Integration Testing: Implementing native tests within the current repository to validate internal logic.
• Downstream Integration Repository: Creating a dedicated "beta/test" repository that consumes this project. This would act as a real-world smoke test for new releases.
• CI Matrix Testing: Running the tool against multiple environments (e.g., different OS or Erlang versions) to ensure compatibility.

Implementation Plan

• Discovery: Evaluate which parts of the codebase are most "brittle" and require immediate coverage.
• Tooling: Select a testing framework (e.g., eunit, common_test, or a shell-based framework if testing a CLI).
• Automation: Integrate the test suite into GitHub Actions to block PRs that break existing functionality.
• Beta Channel: Determine if a separate v-next branch or a dedicated test repo is necessary for staging changes.

Success Criteria

• Baseline test coverage established for core logic.
• CI pipeline configured to run tests on every Push/Pull Request.
• (Optional) A secondary repository configured to run "canary" tests against beta versions.