Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Document unit-test / theory-data impact of .NET 11 double→decimal conversion

Open Beginner friendly
  • Is something wrong?
#56,487 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@SkyDevLab is already working on this.

Since Oct 21, 2026.

  • #56516 by @SkyDevLab — open

Assessment

Difficulty
1/5
Estimated time
1-3 hours
Newbie friendliness
88/100
Issue type
Documentation
Clarity
Clearly specified
Activity status
Active
Tech stack
csharp
Domain
documentation

Research direction

Start with docs/core/compatibility/core-libraries/11/decimal-biginteger-floating-point-conversions.md and check the existing Recommended action section; the related .NET 11 libraries page is docs/core/whats-new/dotnet-11/libraries.md. Add a concise unit-test impact subsection with the xUnit and NUnit guidance and examples described in the issue. Done when the page explains how floating-point test data converts to decimal and shows decimal-preserving alternatives.

Written by the indexing model from the issue text.

Description

:watch: Not Triaged dotnet-fundamentals/svc
Type of issue
  • Content issue (typos, broken links, missing/outdated content)
  • Product issue (bug in docs tooling/platform)
Location
Description

The breaking-change page correctly documents that float/double → decimal is now correctly rounded (exact binary value), and recommends decimal literals (1.23m) instead of casting double literals.

What is easy to miss in migration: unit-test theory / inline data often injects floating literals as double, then binds or casts them to decimal parameters. That path was “quietly OK” on .NET 10 (15-digit-style conversion) and fails equality / validation on .NET 11 even when production code already uses decimal end-to-end.

xUnit
// Compiles: 0.1 is a double attribute argument
[Theory]
[InlineData(0.1)]
public void Rate(decimal rate)
{
    // Under .NET 10: rate often equals 0.1m
    // Under .NET 11: rate == 0.1000000000000000055511151231m  → assert fails
    Assert.Equal(0.1m, rate);
}

// Does NOT compile: decimal is not a valid C# attribute argument type
// [InlineData(0.1m)]

Workaround that keeps real decimals: MemberData / ClassData / TheoryData<decimal> with 0.1m values (not attribute args).

NUnit
// Non-m literals become double, then convert to decimal param
[TestCase(0.1)]
public void Rate(decimal rate) { ... }

// Prefer:
[TestCase("0.1")]
public void Rate(decimal rate) { ... } // parsed as decimal
Why document this on the BC page
  • The failure mode is often tests only, so teams can think production is broken when CI is.
  • It is not obvious that InlineData(0.1) + decimal is a double conversion (C# forbids 0.1m in attributes).
  • Same BC already says “don’t assume a binary FP literal and a decimal literal with the same source text represent the same value” — a short “Impact on unit tests” subsection with xUnit/NUnit examples would catch a large class of migration failures.
Suggested addition (sketch)

Under Recommended action, add something like:

Unit tests (xUnit / NUnit / similar)
Theory/case attributes cannot take decimal constants in C#. Non-integer numeric attribute args are double/float. Binding those to decimal parameters uses the same conversion as (decimal)double and therefore changes under this BC. Prefer:

  • xUnit: TheoryData / MemberData with decimal values (0.1m), or string data + decimal.Parse
  • NUnit: [TestCase("0.1")] into decimal, or explicit 0.1m only outside attributes
Page URL

https://learn.microsoft.com/en-us/dotnet/core/compatibility/core-libraries/11/decimal-biginteger-floating-point-conversions

Related
  • Runtime BC is intentional; this is a docs request only (no ask to revert conversion).
  • xUnit docs request: https://github.com/xunit/xunit/issues/3658
  • xUnit attribute limitation is language-level (decimal not allowed in attribute arguments).

Related Issues

Dominant language
No language data
Stars
4.8k
Forks
6.1k
Avg merge
1d 7h
Merged PRs (30d)
222

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from dotnet/docs

All issues in dotnet/docs

Similar issues

More Documentation issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.