TestContext.TestTempDirectory Property
Definition
Important
Some information relates to prerelease product that may be substantially modified before it’s released. Microsoft makes no warranties, express or implied, with respect to the information provided here.
Gets a temporary directory unique to the currently executing test.
public virtual string? TestTempDirectory { get; }
member this.TestTempDirectory : string
Public Overridable ReadOnly Property TestTempDirectory As String
Property Value
Remarks
The directory is created on first access (lazily) and is unique to the currently executing test, including each data-driven case of a [DataRow]/[DynamicData] method. Because every test (and every data case) gets its own directory, tests can write to it concurrently without any coordination — even when the assembly runs in parallel.
This is a *per-test* directory, so it returns null when accessed outside of a test — for example from [AssemblyInitialize], [ClassInitialize], [ClassCleanup], or [AssemblyCleanup] — where there is no single owning test.
The directory is deleted automatically when the test passes and retained when the test fails, so a failed test's artifacts remain available for inspection. Retention of all directories (including passing tests) can be forced for debugging via the MSTEST_TEST_TEMP_DIRECTORY_RETAIN environment variable. A passing test's directory is also retained when the test registers a file inside it as a result attachment via AddResultFile(String), since the host collects that attachment after the test completes.
Unlike TestRunDirectory, DeploymentDirectory, ResultsDirectory, TestRunResultsDirectory, and TestResultsDirectory — which are shared across tests for the whole run — this directory is private scratch space owned by a single test. Use it for files a test needs to write during execution; use the result directories for files that should be collected as run artifacts.
On Windows the returned path is kept short enough to reserve roughly 80 characters of headroom under the classic MAX_PATH (260) limit for the files the test itself writes, so ordinary relative paths created inside it will not overflow MAX_PATH. The feature targets the 260-character limit and does not rely on long-path opt-in (LongPathsEnabled / the \\?\ prefix), which is not guaranteed to be enabled and is often not honored by external tools. If the run's results directory is too deep to preserve that headroom, or cannot be written to (for example a read-only output directory), the directory is created under the system temporary directory instead.