Skip to content

Add RFC 016: Union Types in Data-Driven Tests#8612

Draft
Evangelink wants to merge 1 commit into
mainfrom
dev/amauryleve/rfc-016-union-types-data-driven
Draft

Add RFC 016: Union Types in Data-Driven Tests#8612
Evangelink wants to merge 1 commit into
mainfrom
dev/amauryleve/rfc-016-union-types-data-driven

Conversation

@Evangelink
Copy link
Copy Markdown
Member

Draft RFC for review — design exploration only, no implementation in this PR.

Addresses #7741: should MSTest support C# union types ([System.Runtime.CompilerServices.Union]) in data-driven tests?

What the RFC does

  • Sets out the actual current behaviour after reading the source (TestMethodInfo.ResolveArguments does no conversion at all; DataRowShouldBeValidAnalyzer rejects via ClassifyCommonConversion).
  • Distinguishes the four code paths (classic reflection adapter, MTP source-gen [DataRow], MTP source-gen DynamicData, AOT source-gen) and explains how each is — or isn't — affected.
  • Recommends a conservative, transparent design: a single shared conversion rule used by both analyzer and runtime, gated on a metadata-observable case-discovery contract from the language.
  • Considers and rejects: automatic combinatorial expansion (no way to pick sample values), a separate [UnionDataRow] attribute (splits API for no real reason), source-generator-only path (heavy machinery for a small problem).
  • Explicitly preserves the "do nothing" option — if the language ships unions without a metadata-observable case contract, the recommendation collapses to documentation + an optional TestDataRow.OfUnion<T>(...) helper.

What I'd appreciate review on

  1. The analyzer/runtime alignment story — is StandardConversion.TryConvert over a small spec-defined set realistic, or should we narrow further?
  2. The case-discovery contract preferences (op_Implicit > [UnionCase] > constructors-as-fallback). Does anyone have inside knowledge of where the language design is headed?
  3. The version-skew floor — is the analyzer-needs-to-know-adapter-version pattern something we've done before? Is there a precedent in the repo?
  4. The phasing: shipping analyzer + runtime + params + AOT all in Phase 1 is intentionally conservative against the "analyzer green, runtime red" trap. Pushback welcome.

Not ready to be marked Approved; opening as draft to start discussion.

Draft design for handling C# [Union] parameter types in MSTest's data-driven testing surface (DataRow, DynamicData, ITestDataSource, DataRowShouldBeValidAnalyzer).

Tracks #7741.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot AI review requested due to automatic review settings May 26, 2026 14:59
Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This pull request adds a draft design RFC (RFC 016) to explore how MSTest could support upcoming C# union types ([System.Runtime.CompilerServices.Union]) in data-driven tests, with an emphasis on keeping analyzer and runtime behavior aligned and deferring implementation until the language exposes a metadata-observable case contract.

Changes:

  • Add RFC 016 describing current MSTest behavior for argument binding and analyzer validation with unions.
  • Propose a phased approach for potential support across classic adapter and MTP source-generation paths.
  • Document open questions (Roslyn conversion surface, case discovery contract, AOT/trimming, package version skew).
Show a summary per file
File Description
docs/RFCs/016-Union-Types-In-Data-Driven-Tests.md New RFC draft laying out motivation, current behavior, proposed design, rollout phases, and open questions for union-type support in data-driven tests.

Copilot's findings

  • Files reviewed: 1/1 changed files
  • Comments generated: 2

Comment on lines +200 to +201
is decorated with `UnionAttribute`:

Comment on lines +244 to +249
mismatch. The same applies if a method takes a single `StringOrInt[]` parameter and the
data source supplies an `object[]` whose elements are case values.

This is a small but real addition to the implementation: the conversion hook is applied
per-element for any array-typed slot whose element type is a union.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants