Expose results directory through TestContext

[thomhurst]

Summary

• expose the resolved Microsoft.Testing.Platform results directory through TestContext.ResultsDirectory
• initialize it with IConfiguration.GetTestResultDirectory(), preserving --results-directory and configuration overrides
• document artifact creation and add runtime/public API coverage

Testing

• dotnet test tests/TUnit.TestProject/TUnit.TestProject.csproj --framework net10.0 --no-restore --treenode-filter "/*/*/TestContextTests/ResultsDirectory_Is_Exposed"
• same focused test with --results-directory TestResults/issue-6538-override
• dotnet test tests/TUnit.PublicAPI/TUnit.PublicAPI.csproj --no-restore (18 passed)
• dotnet test tests/TUnit.Engine.Tests/TUnit.Engine.Tests.csproj --no-restore (244 passed, 124 skipped)

Fixes #6538

[coderabbitai]

Warning

Review limit reached

@thomhurst, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 4 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: f96c4e96-7c7c-4dde-a6c2-362fab0bb826

📥 Commits

Reviewing files that changed from the base of the PR and between f824dd6 and 14c788e.

📒 Files selected for processing (9)

• docs/docs/writing-tests/artifacts.md
• docs/docs/writing-tests/test-context.md
• src/TUnit.Core/TestContext.cs
• src/TUnit.Engine/Framework/TUnitServiceProvider.cs
• tests/TUnit.PublicAPI/Tests.Core_Library_Has_No_API_Changes.DotNet10_0.verified.txt
• tests/TUnit.PublicAPI/Tests.Core_Library_Has_No_API_Changes.DotNet8_0.verified.txt
• tests/TUnit.PublicAPI/Tests.Core_Library_Has_No_API_Changes.DotNet9_0.verified.txt
• tests/TUnit.PublicAPI/Tests.Core_Library_Has_No_API_Changes.Net4_7.verified.txt
• tests/TUnit.TestProject/TestContextTests.cs

---

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

[greptile-apps]

Greptile Summary

Exposes Microsoft.Testing.Platform's resolved results directory through the public TestContext API and documents its use for generated artifacts.

• Initializes TestContext.ResultsDirectory from the platform configuration during engine startup.
• Adds public API snapshots and runtime coverage for path resolution and directory existence.
• Documents artifact creation using the configured results directory.

Confidence Score: 5/5

The PR appears safe to merge with no actionable defects identified.

The public property is initialized from the same platform results-directory source used by existing reporters, and runtime coverage verifies its resolution, existence, and configuration consistency.

Important Files Changed

Filename	Overview
src/TUnit.Core/TestContext.cs	Adds a guarded public static property exposing the initialized results-directory path.
src/TUnit.Engine/Framework/TUnitServiceProvider.cs	Initializes the new property from Microsoft.Testing.Platform's resolved configuration during provider construction.
tests/TUnit.TestProject/TestContextTests.cs	Verifies the exposed directory is fully qualified, exists, and matches the platform configuration.
docs/docs/writing-tests/artifacts.md	Documents writing and attaching generated files in the results directory.

_{Reviews (1): Last reviewed commit: "feat: expose results directory" | Re-trigger Greptile}

[claude]

Code Review

Reviewed the new TestContext.ResultsDirectory API and its documentation.

Implementation (TestContext.cs, TUnitServiceProvider.cs) looks solid: lazily throws a clear InvalidOperationException if accessed before engine init, sourced correctly from Microsoft.Testing.Platform's GetTestResultDirectory(), public API surface updated consistently across all target frameworks (net8/9/10, net4.7), and covered by a new engine test (ResultsDirectory_Is_Exposed) that asserts it's a fully-qualified, existing directory matching the platform config.

Issue: doc example writes to a fixed shared filename (collision risk under parallel execution)

docs/docs/writing-tests/artifacts.md (new CaptureLog example):

var artifactPath = Path.Combine(TestContext.ResultsDirectory, "application.log");
await File.WriteAllTextAsync(artifactPath, "Diagnostic information");

ResultsDirectory is one process-wide directory, not per-test. TUnit runs tests in parallel by default, so if this pattern is copied by multiple tests (or a data-driven test with multiple cases), each writes to the exact same application.log path concurrently — causing sharing-violation IOExceptions or silently overwritten/lost diagnostic output.

The companion doc this PR also touches (test-context.md) already documents TestContext.Current!.Isolation a few lines below for producing unique per-test resource names — the new example should use that (or another unique-naming scheme, e.g. TestContext.Current!.TestDetails.TestId) to avoid teaching a pattern that breaks under the framework's own default parallelism.

Suggested fix:

var artifactPath = Path.Combine(TestContext.ResultsDirectory, $"application-{TestContext.Current!.Isolation}.log");

Everything else in the PR (implementation, API surface, tests) looks correct and ready to merge once the doc example is fixed.