# Testing strategy and record

MoonSeal keeps filesystem access in the CLI and implements analysis as pure,
deterministic library functions. This allows most behavior to be tested without
temporary directories, network access, or platform-specific fixtures.

## Test layers

| Layer | Coverage |
| --- | --- |
| Manifest parsing | Current `moon.mod`, legacy JSON manifests, dependencies, missing and malformed metadata |
| License analysis | SPDX aliases, compound expressions, exceptions, and common license texts |
| Audit engine | Every built-in finding, scoring, readiness, text, JSON, Markdown, and SARIF output |
| Policy engine | Thresholds, required files, license lists, CI, changelog, security policy, and pinned dependencies |
| Dependency health | Coordinates, versions, duplicates, conflicts, namespaces, purls, and inventory output |
| Baseline comparison | Added, resolved, unchanged, and severity-changed findings |
| Provenance and SBOM | CycloneDX 1.6, in-toto Statement v1, SLSA Provenance v1, and validation warnings |
| CLI integration | Path parsing, filesystem collection, self-scan, policy enforcement, and output selection |

## Local test record

Before a release, maintainers run:

```shell
moon info
moon fmt --check
moon check --target wasm -d
moon test --target wasm
moon build --target wasm --release
moon coverage analyze
```

The authoritative current result is the latest successful GitHub Actions run.
CI uploads the raw coverage report so reviewers can inspect the same evidence
without relying on a manually copied percentage.

## Regression rule

Every behavior change must include an assertion test. Stable, well-defined
results use `assert_eq` or `assert_true`; structured output is validated as JSON
and checked for required interoperability fields. Snapshot updates are not
accepted without an accompanying explanation in the pull request.