test: keep record internals in the record store's own tests

[hatayama]

Summary

• Tests that look inside compile-check's records now live in the record store's own test files. Every other test observes the records only through the store's methods.
• Test-only change; no production code changes.

User Impact

• None. This prepares moving the record store into its own package, where tests outside it can no longer reach its internals.

Changes

• Store tests (record_store_test.go, record_store_baseline_test.go, record_format_test.go):
  • the result manifest tests (reuse, rejection, writes, atomic rename, output hashing), now working from output names instead of compile units;
  • forgetting an assembly's records;
  • generator output hashing;
  • the baseline format checks and the golden record bytes.
• Other tests, rewritten to use the store's methods:

  Was	Now
  reading the baseline or manifest JSON	baseline(t): a usable baseline from the store. The store only returns one whose input key matches its manifest
  baseline file exists	hasBaselineOf: the store's reason does not start with no baseline:. A baseline that disagrees with its manifest is reported as baseline compile is no longer on disk, so a baseline written after a failed compile is still detected
  manifest file exists	hasRecordedCompile: the store's reason is not no baseline: no full compile of this assembly is on record. These assemblies are too small to get a baseline, so that reason only means no compile result is recorded
  hashes of four named files	outputSnapshot: every file under the output directory that belongs to the assembly, except the changed-files check's own response file
  editing record JSON by hand	recording a failed compile, or a tampered key, through the store
  generated file count from the record	counting the files under the generator output directory
  blocking the manifest path	a failed compile whose output directory is removed during the compile, so only the record write fails
  removing outputs, then checking each record file	removeUnitOutputs, then the two outputs are gone and the store has no compile result, no baseline and no generator output

Verification

• git grep -P over the test files outside the store's own test files, for record internals (struct names, constants, paths, internal functions, record file names): no matches.
• Each rewritten check was confirmed with a mutation, restored afterwards; each mutation fails the listed tests:
  • forgetting skips the manifest: the two manifest-absence tests and the removeUnitOutputs test fail;
  • recording after a compile error, then returning the error: the three record-nothing tests fail;
  • recording when the compiler failed without a diagnostic: the matching test fails;
  • recording a successful compile with a missing output: the matching test fails;
  • recording a baseline after a failed compile: the matching test fails;
  • writing a baseline and then refusing the missing non-source key: the matching test fails;
  • ignoring a record write failure: the matching test fails;
  • rewriting the manifest during a changed-files check: the matching test fails.
• The fallback order and record format tests still catch all eight mutations they were checked with when they were added.
• No expected reason, byte or count changed.
• cli/dispatcher: golangci-lint fmt --diff (empty), go vet ./..., golangci-lint run (0 issues), the complexity config (0 issues), go test ./..., and go test -race ./internal/compilecheck/... pass. Coverage with the CI exclusions: 94.30% (baseline 94.2).
• cli/release-automation: go test ./... passes. The file-length check passes.

[coderabbitai]

Note

Currently processing new changes in this PR. This may take a few minutes, please wait...

⚙️ Run configuration

• Configuration used: Repository: hatayama/unity-cli-loop/.coderabbit.yaml
• Review profile: CHILL
• Plan: Advanced
• Run ID: 8b8b2564-fd07-4df8-9c1c-fd0e6a1a9f11

📥 Commits

Reviewing files that changed from the base of the PR and between 462f57d and ff4cfac.

📒 Files selected for processing: 1

• cli/dispatcher/internal/compilecheck/scheduler_cache_test.go

+--------------------------------------------------------------------------------------------------------------------------+
| Unix was not designed to stop its users from doing stupid things, as that would also stop them from doing clever things. |
+--------------------------------------------------------------------------------------------------------------------------+
  \
   \   (\__/)
       (•ㅅ•)
       / 　 づ

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

• Configuration used: Repository: hatayama/unity-cli-loop/.coderabbit.yaml
• Review profile: CHILL
• Plan: Advanced
• Run ID: 27991171-c362-4de5-8080-98ccfb4f7b9a

📥 Commits

Reviewing files that changed from the base of the PR and between 38cb0b0 and 462f57d.

📒 Files selected for processing: 10

• cli/dispatcher/internal/compilecheck/baseline_record_test.go
• cli/dispatcher/internal/compilecheck/fast_path_fixture_test.go
• cli/dispatcher/internal/compilecheck/fast_path_order_test.go
• cli/dispatcher/internal/compilecheck/fast_path_test.go
• cli/dispatcher/internal/compilecheck/record_format_test.go
• cli/dispatcher/internal/compilecheck/record_store_baseline_test.go
• cli/dispatcher/internal/compilecheck/record_store_test.go
• cli/dispatcher/internal/compilecheck/result_cache_test.go
• cli/dispatcher/internal/compilecheck/result_cache_write_test.go
• cli/dispatcher/internal/compilecheck/scheduler_cache_test.go

💤 Files with no reviewable changes: 1

• cli/dispatcher/internal/compilecheck/result_cache_test.go

Included review availability: This review used your included allowance. Your plan provides up to 4 included reviews per hour; 0 remain after this review.

📝 Walkthrough

Compile-check tests now use record-store APIs to inspect baselines, compile results, and generated outputs. The changes add record-store coverage for result reuse, baseline loading, output hashing, and record cleanup, and update fast-path and scheduler assertions.

Changes: Compile-check record-store tests

Layer / File(s)	Summary
Baseline and record format coverage cli/dispatcher/internal/compilecheck/baseline_record_test.go, cli/dispatcher/internal/compilecheck/record_format_test.go, cli/dispatcher/internal/compilecheck/record_store_baseline_test.go	Baseline and serialization tests use directory-backed record-store operations. New tests check generated C# file hashing and loading an older-format baseline.
Compile-result reuse and record lifecycle cli/dispatcher/internal/compilecheck/record_store_test.go, cli/dispatcher/internal/compilecheck/result_cache_test.go, cli/dispatcher/internal/compilecheck/result_cache_write_test.go	New tests cover result reuse, diagnostics, write and hashing errors, and record cleanup. Earlier cache tests were removed or replaced.
Fast-path record-store checks cli/dispatcher/internal/compilecheck/fast_path_fixture_test.go, cli/dispatcher/internal/compilecheck/fast_path_order_test.go, cli/dispatcher/internal/compilecheck/fast_path_test.go	Fast-path tests retrieve baselines and generated directories through record-store helpers. Output snapshots and mismatch cases use store-backed records.
Scheduler compile-record checks cli/dispatcher/internal/compilecheck/scheduler_cache_test.go	Scheduler tests check compile-record presence and removal through record-store helpers across compile states.

Priority: ⬇️ Low

Estimated code review effort: 3 (Moderate) | ~20 minutes

Change: Other

Merge Risk: ⚪ Minimal · up to 462f5

This is a test-only reorganization with no user-facing behavior change. No merge-blocking risk is evident.

Pre-merge checks: 5

Passed checks: 5 passed

Check name	Status	Explanation
Description check		The description clearly explains that record-internal tests moved into record store tests and that other tests now use store methods. It also states the change is test-only and provides validation det…
Title check		The title clearly and concisely describes the main change: keeping record-internal tests in the record store's own tests.
Docstring Coverage		Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 48 functions across 9 files.
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

📝 Generate docstrings

• Commit to this branch
• Create a new PR

🧪 Generate unit tests (beta)

• Commit to this branch
• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}