Add a golden/regression test suite and CI

[ssiddhantsharma]

Hi maintainers, I use PLAAC in my routine workflows and wanted to add automated tests for the PLAAC CLI, plus CI to run them.

The scoring logic in cli/src/plaac.java currently has no automated test guarding it, so there is no safety net against an edit unintentionally changing results. PLAAC’s output is deterministic, which makes byte-for-byte regression testing straightforward.

What this adds (pure addition — no changes to plaac.java)

• cli/tests/run_tests.sh — plain bash + java, no test-framework dependency. Two checks:
  1. golden: runs the bundled cli/example/four_classic_prions.fasta at -a 1 -c 60 -d and compares the full output byte-for-byte against a committed expected file. This locks the scored output and the built-in frequency/column tables (from which the web _plaac_headers.haml is generated).
  2. recovery: asserts the four classic yeast prions (Sup35, Ure2, Rnq1, Mot3) each get a called PrLD (PRDlen > 0), a semantic check that survives a reviewed, intentional regeneration of the golden file.
• cli/tests/expected/four_classic_prions.a1.c60.txt — the golden file.
• cli/tests/regenerate_golden.sh — regenerates the golden for reviewed numeric changes.
• cli/tests/README.md — docs.
• .github/workflows/ci.yml — builds plaac.jar and runs the suite on push/PR (JDK 17), and uploads the actual output as an artifact.

Reproducibility

PLAAC scores use Math.log/Math.exp (platform intrinsics), so I verified the output is byte-identical across macOS/arm64 and Linux/x64 (Temurin 17) before committing; the harness also pins the JVM locale so number formatting is host-independent. CI is green.

Notes

• No behavior changes; nothing outside cli/tests/ and .github/ is touched.
• Happy to follow up separately with CLI input-validation hardening (friendlier errors for non-numeric args, etc.) if that would be useful.

[ssiddhantsharma]

Thanks for maintaining PLAAC! After opening this I saw that the devel branch already has a regression test cli-unit-test.yml builds the jar and diffs MOT3.fasta output against a gold file on a Java 11/17 matrix, so this PR largely duplicates work you have already done. Closing it to avoid the redundancy.

I have opened #19 against devel with the part that is not already there: command-line input validation (a friendly error + non-zero exit for non-numeric numeric args instead of a raw stack trace, unknown-option diagnostics moved off stdout so they no longer land in the TSV, and a warning when a value-taking flag is given no value). It keeps the MOT3 gold output byte-identical and leaves the -V / versioning work untouched. Happy to adjust if you would prefer a different approach.