Skip to content

docs: add the rule and the skill for test scenarios - #70

Merged
xperiandri merged 2 commits into
mainfrom
docs/test-scenarios
Oct 18, 2026
Merged

xperiandri merged 2 commits into
mainfrom
docs/test-scenarios

Conversation

@xperiandri

@xperiandri xperiandri commented Oct 18, 2026 •

Copy link
Copy Markdown
Collaborator

Proposed Changes

A scenario is a class that writes the data of a test class into the database of each test before the test starts. The tests read this data. They do not write it. This pull request writes down how to make a scenario. It also makes the two scenarios of the repository obey the new rule. The review of #67 asked for this rule: "If you always seed the same data why don't you derive from OperationTestBase<> with scenario?"

  • SingleItemScenario and MultipleItemsScenario are now in files of their own in tests/Cosmos.Tests/Scenarios/, each in a namespace of its own. Each scenario creates its data in the constructor of TestApplicationFactory and writes the data in SeedDataAsync. The tests read the values from a [<Struct>] record TestData with a record pattern. They refer to the TestApplicationFactory of a scenario through the namespace of the scenario, for example OperationTestBase<SingleItemScenario.TestApplicationFactory>. Thus the test class shows which scenario it uses. They open the namespace for the other types of the scenario. Before this change, MultipleItemsScenario gave an F# list. Thus each test had to match the list and fail on a wrong length.
  • .github/instructions/test-scenarios.instructions.md has only the rules that apply to each test file: when a scenario is necessary, when a test writes its own data, and how a test refers to a scenario. Copilot uses it for tests/**/*.fs, and Claude Code reads it through .claude/rules/test-scenarios.md. The procedure is not repeated there: an instructions file loads with each test file, a skill loads only when an agent writes a scenario.
  • .github/skills/test-data-seeding/SKILL.md tells how to write a scenario and its test class. It comes from the skill with the same name in the application of the maintainer. It is changed for the test infrastructure of this repository: DatabaseTestApplicationFactory, OperationTestBase<_> and CosmosAssert. Its two examples compile, and the example test passes on the emulator. Copilot finds the skill in .github/skills (skill locations). Claude Code finds it through the .claude/skills junction that Directory.Build.targets creates. This is the first skill of the repository, so the junction did not exist before.

Types of changes

What types of changes does your code introduce to FSharp.Azure.Cosmos?
Put an x in the boxes that apply

  • 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)

The change has no effect on the library. It changes only tests and instructions.

Checklist

  • Build and tests pass locally: the 14 tests of the categories "Read", "Read many" and "Iteration extensions" pass on the Windows emulator.
  • 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

#67 builds on this pull request. Its scenario DurationsScenario has the same form.

🤖 Generated with Claude Code

Copilot AI balanced review requested due to automatic review settings October 18, 2026 00:57

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟢 Approval recommended

The refactor preserves existing seeding behavior, and no blocking issues remain.

No open issues 🎉

What changed in this PR

Documents the reusable emulator test scenario pattern requested in #67 and updates existing tests to follow it, without changing the library.

Changes:

  • Adds scenario rules and a test-data-seeding skill.
  • Extracts both scenarios into dedicated files with struct TestData records.
  • Updates tests to read seeded values through record patterns.
File Description
tests/​Cosmos.Tests/​Scenarios/​SingleItemScenario.fs Extracts the single-item scenario.
tests/​Cosmos.Tests/​Scenarios/​MultipleItemsScenario.fs Extracts the two-item scenario.
tests/​Cosmos.Tests/​ReadOperationTests.fs Uses the single-item data record.
tests/​Cosmos.Tests/​ReadManyOperationTests.fs Replaces list matching with record matching.
tests/​Cosmos.Tests/​IterationExtensionsTests.fs Uses the shared two-item data record.
tests/​Cosmos.Tests/​FSharp.Azure.Cosmos.Tests.fsproj Compiles scenarios before their consumers.
.github/​skills/​test-data-seeding/​SKILL.md Provides scenario guidance and examples.
.github/​instructions/​test-scenarios.instructions.md Defines test scenario rules.
.claude/​rules/​test-scenarios.md Shares the rules with Claude Code.

Review effort: Balanced

Comment thread .github/instructions/test-scenarios.instructions.md Outdated
SingleItemScenario and MultipleItemsScenario were in the files of their
tests and gave their items through members. MultipleItemsScenario gave
an F# list. Thus each test had to match the list and fail on a wrong
length.

Move each scenario into tests/Cosmos.Tests/Scenarios, in a namespace of
its own. Each scenario creates its data in the constructor of its
TestApplicationFactory and writes the data in SeedDataAsync. It gives
the values that the tests read through a [<Struct>] TestData record,
and the tests read the values with a record pattern.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
An emulator test class that writes the same data in each test repeats
the setup in each test and hides what the test examines. The
instructions did not tell how tests get seeded data.

Add .github/instructions/test-scenarios.instructions.md, which Claude
Code reads through .claude/rules/test-scenarios.md. It has only the
rules that apply to each test file: when a scenario is necessary, when
a test writes its own data, and how a test refers to a scenario. The
rules load with each test file, so the file stays short.

Add the skill test-data-seeding in .github/skills. It has the
procedure: how to write a scenario, its TestData record and the test
class, with examples that compile. A skill loads only when an agent
writes or changes a scenario. Claude Code finds the skill through the
.claude/skills junction that Directory.Build.targets creates.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@xperiandri
xperiandri merged commit 98323a7 into main Oct 18, 2026
7 checks passed
@xperiandri
xperiandri deleted the docs/test-scenarios branch October 18, 2026 14:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants