test (docs) Guide for writing e2e tests that take summaries

[agarwal-navin]

Description

Adds a new doc, WritingTestsThatTakeSummaries.md, to the test-end-to-end-tests package documenting the pattern for writing end-to-end tests that drive summaries on demand. It covers:

• The two container configurations — interactive containers (with the automatic summarizer disabled) vs. the dedicated summarizer.
• How to take a summary with summarizeNow and inspect the result.
• How to load a new container or summarizer from a specific summary version.
• The rules that keep these tests deterministic (syncSummarizer: true, ensureSynchronized() before summarizing, chaining via summaryVersion, closing one summarizer before starting another, etc.).

It also adds a Table of Contents and an Introduction section to the package README.md and WritingCompatCorrectTests.md for consistency and navigation, links the new doc from the README, and fixes a heading typo ("Enpdoint" → "Endpoint") in the README.

Documentation-only change — no code or public API is affected.

[Copilot]

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

[github-actions]

Hi! Thank you for opening this PR. Want me to review it?

Based on the diff (332 lines, 4 files), I've queued these reviewers:

• Correctness — logic errors, race conditions, lifecycle issues
• Security — vulnerabilities, secret exposure, injection
• API Compatibility — breaking changes, release tags, type design
• Performance — algorithmic regressions, memory leaks
• Testing — coverage gaps, hollow tests

How this works

• Adjust the reviewer set by ticking/unticking boxes above. Reviewer toggles alone don't trigger anything.

• Tick Start review below to dispatch the review fleet.

• After review finishes, tick Start review again to request another run — it auto-resets after each dispatch.

• This comment updates as new commits land; your reviewer selections are preserved.

• Start review

[markfields]

This is great!

[github-actions]

🔗 No broken links found! ✅

Your attention to detail is admirable.

linkcheck output

> fluid-framework-docs-site@0.0.0 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"


> fluid-framework-docs-site@0.0.0 serve
> docusaurus serve --no-open

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

> fluid-framework-docs-site@0.0.0 check-links
> linkcheck http://localhost:3000 --skip-file skipped-urls.txt

Crawling...

Stats:
  290871 links
    1933 destination URLs
    2183 URLs ignored
       0 warnings
       0 errors

[Josmithr]

Nit: our best practices docs for Markdown recommend line-breaking along sentence boundaries. This helps make future changes easier to review.
https://github.com/microsoft/FluidFramework/wiki/Markdown-Best-Practices#line-breaks-along-sentence-boundaries

[Josmithr]

Since this is the first code example demonstrating the test flow, it might be worth including additional boilerplate beforehand, including where provider comes from (or at least a quick note about it)

[Josmithr]

Actually, having read the rest of the document, including more code here probably doesn't make sense. But a quick note that provider will be explained more later in the document might be useful.

[Josmithr]

A thought: since we don't want this to get out-of-date, it might be worth checking this in as an actual test in code (if it isn't already). Then we could use our markdown-magic pragmas to embed the code here, rather than copying it. That way, if we end up having to update this example for one reason or another, our docs won't become out-of-date.

[Josmithr]

An example of this pattern can be found here: https://github.com/microsoft/FluidFramework/blob/main/tools/api-markdown-documenter/README.md?plain=1#L225

[Josmithr]

I left a couple nitpicks and mechanical suggestions, but the docs look great! Thanks for doing this!