test: compare SQL with golden baselines that can be rewritten

[xperiandri]

Proposed Changes

The planned translator (ADR 0001, #34) turns F# quotations into SQL, and its tests need to say "this quotation becomes exactly this SQL with these parameters". Written inline, hundreds of such expected strings are hard to read and to update when a rule changes on purpose. ADR 0001 therefore plans golden baselines: the expected SQL lives in files checked into the test project, a test compares what it produced with its file, and a deliberate change is accepted by rewriting the files from a test run and reviewing them in the diff, instead of editing strings by hand. This pull request adds that mechanism to the shared test infrastructure, before its first users: the printer tests of the SQL model (#42) and later the translator tests.

tests/Cosmos.Tests.Infrastructure/Baseline.fs:

• Baseline.assertMatches directory suite caseName sql parameters compares the SQL with Baselines/<suite>/<case>.sql, ignoring whitespace, so a baseline may be laid out over several lines. It compares the parameters with <case>.params.json as JSON. A query without parameters has no parameter file.
• With COSMOS_REWRITE_BASELINES=1 the test writes both files instead of comparing. It keeps the layout of the SQL, writes the JSON indented with LF line breaks, and reports itself inconclusive, so a rewriting run never looks like a passing one. On CI (CI=true) rewriting is refused.
• Baseline.directoryOf assembly finds the Baselines directory next to the project file of a test assembly by walking up from where the assembly runs. Unlike [<CallerFilePath>], this does not depend on how the compiler records source paths.

tests/Cosmos.Tests/BaselineTests.fs (12 emulator-free cases) covers matching despite layout, a different SQL, different parameters, a missing baseline, rewriting with and without parameters, invalid case names and finding the directory. .github/copilot-instructions.md lists the new environment variable with the other test variables.

Types of changes

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Test infrastructure only; the package is unchanged.

Checklist

• Build and tests pass locally
• I have added tests that prove my fix is effective or that my feature works (if appropriate)
• I have added necessary documentation (if appropriate)

Further comments

• The new tests: Debug 12/12 and Release 12/12. No new warnings; Fantomas is clean.
• Nothing uses the baselines yet, so no Baselines directory exists so far. The first test that calls assertMatches creates its files through a rewriting run.

🤖 Generated with Claude Code

[Copilot]

🟡 Changes recommended

SQL normalization can hide semantic differences, and suite-name validation permits escaping the baseline directory.

1 open finding

• Use sequence expressions instead of Seq.append · New

What changed in this PR

Adds reusable golden-baseline infrastructure for forthcoming SQL printer and quotation-translator tests.

Changes:

• Adds SQL/parameter comparison and baseline rewriting.
• Adds 12 emulator-free baseline tests.
• Documents the rewrite environment variable.

File	Description
tests/​Cosmos.Tests.Infrastructure/​Baseline.fs	Implements baseline handling.
tests/​Cosmos.Tests.Infrastructure/​FSharp.Azure.Cosmos.Tests.Infrastructure.fsproj	Includes the infrastructure module.
tests/​Cosmos.Tests/​BaselineTests.fs	Tests baseline behavior.
tests/​Cosmos.Tests/​FSharp.Azure.Cosmos.Tests.fsproj	Includes the new tests.
.github/​copilot-instructions.md	Documents baseline rewriting.

🧠 Review effort: Balanced

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[xperiandri]

Should we use Literal type provider?

[xperiandri]

Should we use Literal type provider?

I tried it: FSharp.Data.LiteralProviders 1.0.3 with its TextFile provider, in a prototype on SDK 10.0.401 with MSTest 4. It works there, but it does not fit the baselines, so I would keep the files that are read at run time.

• The literal is frozen at compile time. After COSMOS_REWRITE_BASELINES=1 rewrites a baseline, the next dotnet build does not recompile, and the test compares with the old text. It recompiles only when the files are declared as compile inputs (CustomAdditionalCompileInputs or EmbeddedResource), and then every rewrite costs a rebuild before the next run.
• A case cannot be looked up by a name known at run time. TextFile<caseName> needs a constant (FS0267), and the provided types are erased, so there is nothing to reflect over. The data-driven tests, whose DynamicData rows carry a case name, would need a hand-written match from every case name to its literal.
• The provider resolves paths against the project being compiled. In the shared test infrastructure project the baselines of a test project do not exist: Text is "" and Exists is false, without an error. So Baseline could not own the lookup; every test project would spell every literal and pass it in.
• A new case cannot be started with the rewrite switch. The navigation form, TextFile.Baselines.Suite.case.sql.Text, does not compile until the file exists, and the path form gives an empty string without an error.
• The literal keeps the line endings of the checkout, CRLF on Windows and LF on Linux. That is harmless only because the comparison normalizes whitespace.

What it would give: a compile error for a mistyped case name that is written in the code, and literals that an attribute argument can take. That fits inputs that are written by hand and only read, not outputs that the tests rewrite.

If the build should fail for a missing baseline, <EmbeddedResource Include="Baselines/**/*" /> did that in the prototype without a package. The rewrite switch still needs the source directory then, as it does now.

Not checked: Linux (the prototype ran on Windows only) and the IDE; the package has no release since 2022, and its own CI does not cover .NET 10.