Equivalence testing

What is tested

• fastqc_data.txt and summary.txt must be byte-identical after applying known-difference patches
• fastqc_report.html must be structurally identical after normalizing embedded images
• SVG charts must be structurally identical after normalizing font and rendering differences
• PNG charts are compared pixel-by-pixel with a configurable tolerance (currently 12%)

What is different

Text output is identical. Some non-text outputs differ because the rendering stack is different:

• PNG charts are rendered via resvg + tiny-skia instead of Java2D. Antialiasing differs, producing 1-2% pixel differences.
• SVG charts use a bundled font (Liberation Sans) instead of system Arial, so text positions shift by a few pixels.
• The HTML report is structurally identical once you strip out the embedded chart images (which differ for the same rendering reasons).

None of this affects analysis results. fastqc_data.txt and summary.txt are byte-identical for FASTQ input, with one deliberate exception for BAM/SAM: quality encoding is taken from the format specification (always Phred+33) instead of inferred from the data, so datasets with no base below Q31 report correct quality scores where Java FastQC misdetects Illumina 1.5 and reports them 31 too low (#6). Reported upstream as s-andrews/FastQC#209 with a matching Java fix submitted in #210; if that merges, the two versions agree again.

CI integration

The comparison runs on every commit and pull request via GitHub Actions. If any strict file differs from reference after patching, the build fails. The HTML report is uploaded as a build artifact on every run (pass or fail) so reviewers can inspect differences visually.

Running locally

cargo build --release
uv run tests/equivalence/compare.py --binary ./target/release/fastqc

Writes the report to tests/equivalence/reports/equivalence_report.html.