Tree schema open polymorphism examples

[CraigMacomber]

Description

Add some examples showing patterns for open polymorphism with tree schema.

These examples are derived from those in #23084, showing cases which motivate that work, but do not (yet) include the examples from that PR showing how it helps. Merging this PR first will help that one better show its value.

Reviewer Guidance

The review process is outlined on this wiki page.

[Josmithr]

Should this not be a test file? I would have expected fooWithBar.spec.ts or fooWithBar.integration.spec.ts or something.

[CraigMacomber]

This documentation defines them to be test files, so they are. Just above this is the definition of what we mean by ".spec" in a file, and these do not meet that. Nowhere in here (or anywhere that I know of) do we define that files without ".spec" in there name are not test files. Historically we have inaccurately followed that convention throughout our repo in a mostly undocumented way. Here in tree we have a documented policy (this file) and thus can make changes to the convention (as done here).

I don't think there is any value in making every kind of test file include ".spec" in its file name. If we wanted something to put in the name of every test file, we would pick something like ".test" (well we went with /src/test/ as path prefix which also works).

".spec" (which I assume is short for "specification test") can have a more useful meaning (defined above in this file) if we don't stick it on everything.

[Josmithr]

Fair enough. I guess my real concern is the overloaded use of ".example.ts". We use that below for examples we want to keep up to date. This seems distinct from that. Seems like it should have a different naming convention.

[Josmithr]

Actually, the new test suite in this PR does use .integration.ts, so I'm guessing this paragraph just needs to be fixed to say that instead of example.ts.

[CraigMacomber]

Oh, .example.ts here is wrong. I was doing that earlier and changed my mind since a lot of examples fit inside of .spec tests. I'll update this

[CraigMacomber]

Done.

[Copilot]

Pull Request Overview

This PR adds a new integration test file demonstrating the "Open Polymorphism" design pattern and updates the testing documentation to clarify guidance for integration tests and examples.

• Adds comprehensive integration tests showing various approaches to implementing open polymorphic schema patterns
• Updates testing documentation to better distinguish integration tests from spec tests and provide guidance on examples
• Demonstrates component-based composition patterns for managing polymorphic schemas

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 9 comments.

File	Description
packages/dds/tree/src/test/openPolymorphism.integration.ts	New integration test file containing examples and tests for open polymorphism design patterns with schema composition utilities
packages/dds/tree/src/test/README.md	Updated test documentation to add integration test guidelines and examples section

[github-actions]

🔗 Found some broken links! 💔

Run a link check locally to find them. See
https://github.com/microsoft/FluidFramework/wiki/Checking-for-broken-links-in-the-documentation for more information.

linkcheck output

> [email protected] ci:check-links /home/runner/work/FluidFramework/FluidFramework/docs
> start-server-and-test "npm run serve -- --no-open" 3000 check-links

1: starting server using command "npm run serve -- --no-open"
and when url "[ 'http://127.0.0.1:3000' ]" is responding with HTTP status code 200
running tests using command "npm run check-links"


> [email protected] serve
> docusaurus serve --no-open

[SUCCESS] Serving "build" directory at: http://localhost:3000/

> [email protected] check-links
> linkcheck http://localhost:3000 --skip-file skipped-urls.txt

 ELIFECYCLE  Command failed with exit code 1.