[thomhurst]

Context: discussion #7044. A user's ClassDataSource<T> constructor wrote to a cache, and a [NotInParallel] test that cleared the cache ran before the test that used the instance. [NotInParallel] did not help because constructors run while tests are built, before scheduling starts.

This PR adds a "When Instances Are Created" section to class-data-source.md. It covers:

• Construction happens at build time for every SharedType. With SharedType.None the constructor can run more than once per row.
• IAsyncInitializer.InitializeAsync runs at execution time, within the test's [NotInParallel] constraint.
• It recommends InitializeAsync over the constructor for side effects on shared state, with an example, and warns not to use IAsyncDiscoveryInitializer for this.

Verification: I compiled the snippet locally with warnings as errors and ran it 3 times, passing every time. Moving the registration into the constructor makes Product_Is_Cached fail every time, which reproduces the report.

Summary by CodeRabbit

• Documentation
  • Clarified when ClassDataSource instances are created for each sharing mode.
  • Explained when InitializeAsync runs relative to class hooks and tests, and recommended it for shared-state setup side effects.
  • Distinguished IAsyncInitializer from IAsyncDiscoveryInitializer for initialization during test execution.

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-13T14:37:16.915217Z	b00ae59	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

• Configuration used: Organization UI
• Review profile: CHILL
• Plan: Advanced
• Run ID: 18483af9-5f9a-43c4-ae61-f3510ed4b166

📥 Commits

Reviewing files that changed from the base of the PR and between e573749 and b00ae59.

📒 Files selected for processing (1)

• docs/docs/writing-tests/class-data-source.md

Included review availability: This review used your included allowance. Your plan provides up to 8 included reviews per hour; 6 remain after this review.

📝 Walkthrough

The documentation explains when ClassDataSource<T> instances are constructed and when IAsyncInitializer.InitializeAsync runs. It also describes the timing of class hooks and parallelism constraints, and advises where to place shared-state side effects.

Changes: ClassDataSource documentation

Layer / File(s)

Summary

Construction and initialization timing docs/docs/writing-tests/class-data-source.md

Documents construction during test building for each SharedType, including repeated construction with SharedType.None. It distinguishes construction from execution-time initialization and describes the timing of [Before(Class)] hooks and [NotInParallel] constraints. The example places shared-state side effects in IAsyncInitializer.InitializeAsync rather than the constructor or IAsyncDiscoveryInitializer.

Priority: ⬇️ Low

Estimated code review effort: 1 (Trivial) | ~4 minutes

Change: Other

Merge Risk: ⚪ Minimal · up to b00ae

This is a documentation-only change and its explanation matches how the code behaves. There is no runtime or production risk, so it is ready to merge.

Pre-merge checks · 5

Passed checks (5 passed)

Check name	Status	Explanation
Description Check		Check skipped - CodeRabbit’s high-level summary is enabled.
Title check		The title clearly and concisely describes the main documentation change: explaining when ClassDataSource instances are created.
Docstring Coverage		No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0…
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Commit to this branch
• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{I’m a rabbit with a test in view,
I read when instances come anew.
I’ll wait for InitializeAsync to start,
And keep shared-state changes apart.
Then hop through tests, with timing clear,
And nibble docs with both ears perked here.}

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

Review

Docs-only change, and a useful one: it explains the build-time vs. execution-time distinction behind discussion #7044. The lifecycle.md link target exists, and the snippet is self-contained. The PR description says it was compiled with warnings as errors.

Notes (non-blocking):

• The example is order-independent. InitializeAsync runs inside the [NotInParallel] constraint, so Clears_Cache can run before or after it without breaking Product_Is_Cached. A one-line comment saying so would head off readers who assume the tests need a fixed order.
• The claim that InitializeAsync runs 'after the [Before(Class)] hooks' is a precise ordering guarantee. Make sure lifecycle.md states the same thing, so the two pages can't drift apart.
• Consider a short note that SharedType.PerTestSession and SharedType.Keyed instances are initialized once. Registering in InitializeAsync therefore happens once, and a later Clear() won't be re-populated. That is the next pitfall users will hit with this pattern.

Looks good to merge.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: b00ae59acc

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Qualify timing guarantees for static-property injection

When [ClassDataSource<T>] decorates a supported static property, as in tests/TUnit.UnitTests/StaticPropertyDataSourceTests.cs:15-17, the scheduler initializes static properties before grouping parallel constraints (src/TUnit.Engine/Scheduling/TestScheduler.cs:110-117), and that path creates the value and invokes ObjectInitializer.InitializeAsync (src/TUnit.Engine/Services/StaticPropertyHandler.cs:54-73). Consequently, its constructor does not run during ordinary test building and its initializer is neither after [Before(Class)] nor within [NotInParallel]; qualify these guarantees as applying to test/class parameter and instance-property injection, or document static properties separately.

Useful? React with 👍 / 👎.

[greptile-apps]

Confidence Score: 5/5

[Low impact] This documentation change appears safe to merge.

Summary

Adds guidance explaining when ClassDataSource<T> instances are created.

• The class data source guide explains when instances are built and initialized.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A["Build tests: construct data instances"] --> B["Acquire test scheduling lock"]
    B --> C["Run Before(Class) hooks"]
    C --> D["Await InitializeAsync once per instance"]
    D --> E["Run test hooks and body"]
    E --> F["Finish cleanup and release lock"]

Loading

_{Reviews (1) · Last reviewed commit: "docs: explain when ClassDataSource insta..." · Reviewed by Greptile}