feat: expose data source attributes on TestContext

[thomhurst]

Summary

Implements the ask from discussion #6476: data source metadata is now reachable from TestContext.

• TestContext.Metadata.ClassDataSource — the data source attribute instance that generated the test class's constructor arguments
• TestContext.Metadata.MethodDataSource — the data source attribute instance that generated the test method's arguments
• Both are never null: tests without a data source get the NoDataSource no-op singleton (now public sealed with a private constructor), so callers can pattern-match instead of null-checking

This lets a fixture discover its own sharing scope from IAsyncInitializer.InitializeAsync:

if (TestContext.Current?.Metadata.MethodDataSource is ClassDataSourceAttribute<MyFixture> attr)
{
    var shared = attr.Shared; // SharedType.Keyed
    var key = attr.Key;       // "MyKey"
}

Engine bug found & fixed along the way

While validating, the new Fixture_Can_Read_Own_Sharing_Scope_In_InitializeAsync test was flaky: the fixture's InitializeAsync intermittently observed a sibling test's TestContext.Current.

Root cause (pre-existing): in TestExecutor.ExecuteAsync, the session/assembly/class RestoreExecutionContext() calls replay AsyncLocals captured while the first test in that scope ran its hooks — including that test's TestContext.Current. Object initialization (InitializeTestObjectsAsync) ran before the test's own RestoreExecutionContext(), so IAsyncInitializer implementations reading TestContext.Current could see whichever test triggered the class hooks. Fixed by re-pointing TestContext.Current at the executing test before initialization. Stress-ran the suite 10x with zero failures (was failing ~1 in 3 runs before).

Plumbing

• TestBuilderContext gains ClassDataSourceAttribute; TestBuilder populates it at all context-creation sites (batch, streaming, and skip paths). The existing DataSourceAttribute slot (method-level) is unchanged.
• The streaming BuildSingleTestAsync path now uses its explicit classDataSource/methodDataSource parameters (previously the context slot was left null there).

Testing

• New TestContextDataSourceAttributeTests + TestContextConstructorDataSourceTests (6 tests) — pass in both source-gen and reflection modes, stress-ran 10x
• /*/*/TestContext*/* slice (48 tests): pass in both modes
• /*/*/*Hook*/* slice (115 tests): identical results to main (26 intentional failures, byte-for-byte same counts)
• /*/*/ClassDataSource*/* slice: identical results to main (3 pre-existing order-dependent failures under this filter, reproduced on main)
• Public API snapshots regenerated for all 4 TFMs (additions only)

Docs

Added a "Data Source Attributes" section to docs/docs/writing-tests/test-context.md, including the shared-fixture caveat (shared fixtures initialize once, under the first consuming test's context) and a pointer to IKeyedDataSource for the key-only case.

Closes #6476

[greptile-apps]

Greptile Summary

Exposes class- and method-level data-source attributes through test metadata, preserves their provenance across test-building paths, and restores the executing test context before object initialization.

• Adds the public NoDataSource singleton as the non-null metadata fallback.
• Corrects the empty class-data skip path so the class source is not exposed as a method source.
• Adds API snapshots, documentation, and source-generation/reflection coverage.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failures remain in the fix associated with the previous review thread.

Important Files Changed

Filename	Overview
src/TUnit.Engine/Building/TestBuilder.cs	Propagates class and method data-source attributes separately, including the corrected empty-class-data skip path.
src/TUnit.Core/TestContext.Metadata.cs	Exposes non-null class and method data-source metadata with NoDataSource.Instance fallbacks.
src/TUnit.Engine/TestExecutor.cs	Restores the executing test as TestContext.Current before asynchronous object initialization.
src/TUnit.Core/Attributes/TestData/NoDataSource.cs	Makes the no-op data source a public immutable singleton.
tests/TUnit.TestProject/TestContextDataSourceAttributeTests.cs	Covers non-data, method-data, constructor-data, and initializer metadata access scenarios.

_{Reviews (3): Last reviewed commit: "refactor: move data source properties be..." | Re-trigger Greptile}

[claude]

Review: feat: expose data source attributes on TestContext (#6477)

I read through the full diff, traced the data flow through TestBuilder.cs/TestBuilderContext.cs/TestContext.Metadata.cs, and verified the TestExecutor.cs fix against Context.RestoreExecutionContext(). I also built TUnit.Core/TUnit.Engine from the branch and ran the new tests (TestContextDataSourceAttributeTests + TestContextConstructorDataSourceTests, 28 tests in the full slice) 5x in a row — all green, consistent with the PR's stress-test claim.

Overall

Solid, well-scoped change. The new ClassDataSource/MethodDataSource properties are plumbed consistently through all four TestBuilderContext construction sites in TestBuilder.cs (batch, streaming, and skip paths), and the fallback to NoDataSource.Instance avoids null-checks for callers without pushing nullability handling onto every consumer.

Engine bug fix (TestExecutor.cs)

The root-cause analysis is correct: Context.RestoreExecutionContext() replays the entire captured ExecutionContext (including TestContext.Current's AsyncLocal) from whichever test first triggered the session/assembly/class hooks. Re-pointing TestContext.Current right before InitializeTestObjectsAsync is the right fix, and it's consistent with the existing pattern already used in TestCoordinator.cs:98 and TestArgumentRegistrationService.cs:26. Good catch — this was a real, hard-to-spot correctness bug (shared fixtures observing the wrong test's context during IAsyncInitializer), and fixing it here rather than working around it in the new feature is the right call.

One design suggestion (non-blocking)

NoDataSource is now public sealed with mutable SkipIfEmpty/DeferEnumeration auto-properties (required to satisfy IDataSourceAttribute), backing a single process-wide singleton (NoDataSource.Instance). Since the type is now part of the public API, external code can hold a reference to TestContext.MethodDataSource (or the singleton directly) and mutate those properties — which would leak across every test that observes NoDataSource.Instance, since it's shared, not per-test. It's a fairly obscure misuse (nobody has a real reason to flip SkipIfEmpty on a no-op source), and I didn't find any internal code that does this today, but making a mutable singleton part of the public surface is worth a second look:

• Simplest mitigation: a one-line doc comment on Instance warning it's a shared singleton and the setters are inert/should not be used.
• Alternative: back the properties with fields that ignore writes (since they have no behavioral effect on NoDataSource anyway), so misuse is a no-op rather than silent shared-state corruption.

Not a reason to hold up the PR — just flagging it now since the type just became public and this is the easiest point to close the gap.

Verification performed

• Traced classDataSource/methodDataSource plumbing through all TestBuilder.cs construction sites — confirmed the streaming BuildSingleTestAsync path now correctly uses its explicit parameters (matches the PR description) instead of the shared contextAccessor.Current slot.
• Confirmed TestContext.Current's setter also updates ClassHookContext.Current, and that this is consistent with what's already set via the class-context RestoreExecutionContext() call a few lines above the fix — no double-set hazard.
• Built TUnit.Core + TUnit.Engine (net10.0, Release) — clean, no errors/warnings from the changed files.
• Ran /*/*/TestContextDataSourceAttributeTests/* 5x consecutively — 4/4 passed every run (the flaky fixture-sharing test included).
• Confirmed no source-generator changes were needed because both source-gen and reflection modes funnel through the same TestBuilder pipeline — satisfies the dual-mode requirement without generator changes.

No prior review comments existed on this PR to reconcile against.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: d50f70b5be

ℹ️ 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".

[thomhurst]

Addressed both review items in df07ab0:

• greptile P1 (class source leaking into MethodDataSource on the skipped-empty-class-data path): the method slot is now left empty there, so MethodDataSource returns NoDataSource.Instance and only ClassDataSource exposes the class-level source. The class attribute remains discoverable via the declared attributes, so the (previously duplicated) append was the only thing dropped.
• Mutable public singleton: went with the inert-setter option — NoDataSource.SkipIfEmpty/DeferEnumeration now always return false and their setters are no-ops, with doc remarks explaining why. Misuse is a harmless no-op instead of shared-state corruption.

Public API snapshots re-accepted (only a compiler-generated state-machine ordinal changed). TestContext slice (48 tests) re-run green in both source-gen and reflection modes.

[thomhurst]

deef13d: moved the two properties behind the ITestMetadata facade per maintainer feedback — usage is now TestContext.Current?.Metadata.MethodDataSource / .Metadata.ClassDataSource, consistent with the context's grouped-interface organisation. Explicit interface implementations on TestContext, docs/tests updated, API snapshots re-accepted (property moved from class to interface). All 48 TestContext-slice tests green in both source-gen and reflection modes.