[xperiandri]

Proposed Changes

A scenario created its container itself, in SeedDataAsync. The review of #67 asked: "why TestApplicationFactory do not insures all containers are created? delegate it to a virtual method on it". This pull request moves the creation of the containers into the fixture.

• DatabaseTestApplicationFactory has the new virtual member Containers, a ContainerSet. A scenario overrides it to declare the containers that it writes into. InitializeAsync creates them before SeedDataAsync runs. By default, ContainerCount is the number of declared containers, and at least one. Thus a test that creates its containers itself works as before.
• ContainerSet is a set of container definitions with the identifier as key. It throws ArgumentException when a scenario declares a container twice. The reason: CreateContainerIfNotExistsAsync returns a container that exists already and ignores all of its other settings, except the partition key path, so a second declaration would be lost without a message (measured with SDK 3.62.0 and 3.63.2). A plain ImmutableHashSet would hide it too, because it keeps the first of two equal items without a message. The unit tests of the set need no emulator.
• OperationTestApplicationFactory is the base class of the scenarios of the operation tests. It declares the container of OperationTestBase (operation-tests) and gives it to a scenario as Container. A scenario that writes with another serializer gets the container of its own client with GetContainerOf client.
• SingleItemScenario and MultipleItemsScenario use it. They do not create a container and do not repeat its identifier. OperationTestBase uses the same constants.
• The test-data-seeding skill says how to declare containers. Its two examples compile, and the example test passes on the emulator.

The test classes that do not use a scenario are not changed. ReadExtensionsTests creates a second container, and QuerySemanticsTests (#44) creates its containers itself. They keep the default Containers, which is empty.

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 the skill.

Checklist

• Build and tests pass locally: the 8 unit tests of ContainerSet and the 79 tests of the categories "Create", "Read", "Read many", "Replace", "Upsert", "Patch", "Delete", "Read extensions" 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

The scenarios are the tests of the new member: a scenario can write to its container only if InitializeAsync created it.

#67 builds on this pull request. Its scenario DurationsScenario uses OperationTestApplicationFactory.

🤖 Generated with Claude Code

[Copilot]

🟢 Approval recommended

No blocking defects were identified; the remaining documentation clarification is minor.

1 open issue

• Clarify container access for DatabaseTestApplicationFactory · New

What changed in this PR

Moves scenario container creation into the test fixture, leaving scenarios responsible for seeding data. The library is unchanged.

Changes:

• Creates declared containers before seeding and derives the default partition budget from their count.
• Shares operation-test container definitions across fixtures and scenarios.
• Updates the test-data-seeding guidance.

File	Description
tests/​Cosmos.Tests/​Scenarios/​SingleItemScenario.fs	Seeds through the shared operation fixture.
tests/​Cosmos.Tests/​Scenarios/​MultipleItemsScenario.fs	Removes scenario-owned container creation.
tests/​Cosmos.Tests/​OperationTestInfrastructure.fs	Adds the operation fixture and shared container constants.
tests/​Cosmos.Tests.Infrastructure/​IntegrationInfrastructure.fs	Creates declared containers during initialization.
.github/​skills/​test-data-seeding/​SKILL.md	Documents fixture-owned containers and updates examples.

_{Review effort: Balanced}