Document discovery/execution phases and folded vs. unfolded test behavior#53360
Document discovery/execution phases and folded vs. unfolded test behavior#53360Evangelink wants to merge 1 commit intomainfrom
Conversation
There was a problem hiding this comment.
Pull request overview
This PR expands the Unfolding strategy section in the MSTest data-driven testing article to document previously undocumented behavior around discovery-time data evaluation, and how folded versus unfolded results show up in Test Explorer and TRX.
Changes:
- Document MSTest’s discovery-versus-execution behavior for data sources, including lifecycle hook timing implications.
- Clarify folded versus unfolded reporting, and describe fallback-to-folding behavior when discovery-time evaluation throws.
- Apply small style and consistency edits (wording tweaks, heading formatting, and list formatting).
Show a summary per file
| File | Description |
|---|---|
docs/core/testing/unit-testing-mstest-writing-tests-data-driven.md |
Adds discovery/execution and folded/unfolded behavioral details to improve the accuracy and usefulness of the unfolding strategy guidance. |
Copilot's findings
- Files reviewed: 1/1 changed files
- Comments generated: 2
| MSTest processes data-driven tests in two distinct phases: | ||
|
|
||
| 1. **Discovery phase**: MSTest evaluates all data source attributes (`DataRow`, `DynamicData`, `ITestDataSource`) to determine the list of test cases. This evaluation happens *before* any of the regular MSTest lifecycle hooks run—`AssemblyInitialize`, `ClassInitialize`, and other setup methods haven't executed yet. | ||
| 1. **Execution phase**: MSTest runs the normal lifecycle (assembly initialization, class initialization, test initialization, test method, cleanup) and executes each test case with its data. | ||
|
|
There was a problem hiding this comment.
The numbered list under "MSTest processes data-driven tests in two distinct phases" describes concepts, not procedural steps. Convert the ordered list to a bulleted list (or another non-procedural format) to match the repo’s Markdown style guidance for lists.
| For most scenarios, the default `Auto` behavior provides the best balance. Consider changing the unfolding strategy when you have specific requirements: | ||
|
|
||
| - Non-deterministic data sources | ||
| - Known limitations or bugs in MSTest | ||
| - Performance concerns with many test cases | ||
| - Data sources that depend on runtime state or setup logic that isn't available during discovery | ||
| - Non-deterministic data sources that return different values on each evaluation | ||
| - Performance concerns with large numbers of test cases |
There was a problem hiding this comment.
The bullets under "When to change the strategy" are fragments and don’t end with punctuation. Rewrite each bullet as a complete sentence (and add terminal punctuation) to match the doc’s list style in surrounding sections.
Summary
Expands the "Unfolding strategy" section in the data-driven testing article to document important behavioral details that were previously missing.
Changes
AssemblyInitialize,ClassInitialize) run, and that data-generation code can't rely on state from those hooks.TestDataRow, "associated to" → "associated with", numbered list → bullet list for non-procedural best practices.Related to microsoft/testfx#7774
Internal previews