We just shipped Core Framework v3 3.1.0 and Visual Studio adapter 3.1.5.
Check the release notes for new features and bugs fixed.
https://xunit.net/releases/v3/3.1.0
https://xunit.net/releases/visualstudio/3.1.5
Conseils sur l'usage de spyOn et mock avec Vitest.
Cet article m'a enfin permis de comprendre le mocking avec Vitest, et c'est dingue de voir à quel point ces fonctions sont mal nommées 
Au final spyOn fait TELLEMENT PLUS que ce que son nom suggère. Il faudra que j'écrive un article sur le sujet.
https://laconicwit.com/vi-mock-is-a-footgun-why-vi-spyon-should-be-your-default/
We just shipped Core Framework v3 3.2.0-pre.5.
This is specifically for users who wish to try the preview of Microsoft Testing Platform v2. Estimated RTM for 3.2.0 will be close to .NET 10 RTM.
3.1.0 RTM will be later this month.
What joy is there in life if we cannot have some levity in the unit tests we write? https://github.com/gristlabs/grist-core/pull/1775/files#diff-7c5c7527b8a36eb65d4f8d52ac465fa5b0fa5017f25c4f4e409d4244c6be82daR1107
Enhance your CLI testing workflow with the new dotnet test.
https://devblogs.microsoft.com/dotnet/dotnet-test-with-mtp/?hide_banner=true
We just shipped Core Framework v3 3.0.1, Analyzers 1.24.0, and Visual Studio adapter 3.1.4.
Check the release notes for new features and bugs fixed.
https://xunit.net/releases/v3/3.0.1
https://xunit.net/releases/analyzers/1.24.0
https://xunit.net/releases/visualstudio/3.1.4
The last core framework release was July 13. We definitely have enough for a new release next week. If you're so inclined, maybe pick up a CI build and test it before we ship and/or raise awareness of anything you want fixed. https://xunit.net/docs/using-ci-builds
The amount of difficulty in making the @xunit assertion library work in Native AOT has me thinking about whether it needs a complete redesign for those types of projects.
Trying to shove 50 things into `Assert.Equal` and figure out what you meant at runtime is definitely not the right design for AOT. It's not necessarily a great design at all, but there's where it's been for 18 years.
Given that xUnit.net runs tests in random order by default, would changing the randomization order (in order to fix a bug) just be considered a bug fix or a breaking change?
Asking for a SemVer.
Happy birthday @xunit
Version 1.0 was released on July 24, 2007. You're old enough to vote now.
"Microsoft Testing Platform is cool!" by Tomasz Cielecki @Cheesebaron https://blog.ostebaronen.dk/2025/07/ms-test-platform-is-cool.html #DotNet #UnitTest
Using #claude to write #flutter #unittest code in a single sit down session.
Without no logical edits and only sparse missing imports and only a single #aihallucination (a made-up foundation class) it easily achieved >50% pass/fail and >70% #coverage.
Impressive or not?
EDIT: And, yes, this absolutely included reading/code-reviewing all generated code before running the tests.
We just shipped Visual Studio adapter 3.1.3.
This is a bug fix release to address a failure case when running xUnit.net v2 tests (which was introduced in 3.1.0).
We just shipped Core Framework v3 3.0.0, Analyzers 1.23.0, and Visual Studio adapter 3.1.2.
Check the release notes for breaking changes, new features, and bugs fixed.
https://xunit.net/releases/v3/3.0.0
https://xunit.net/releases/analyzers/1.23.0
https://xunit.net/releases/visualstudio/3.1.2
We just shipped a new prerelease build of the core framework (3.0.0-pre.40).
There are no new breaking changes, so this will not reset our release clock for 3.0.0 (which should be in about a week).
Just a reminder that we only have roughly 10 more days of before we ship 3.0. If you've been putting off validating your tests and/or extensions with the latest prerelease, your time is running low...
We just shipped a new prerelease build of the core framework (3.0.0-pre.25).
This includes new breaking changes since last week's prerelease. Please check the release notes for more information.
So made a source generator - ended up rather complex.
But I find unit testing it very tedious when verifying the generated output via Verify.
Is it not possible to load a class/instance as source in the testing, and use it as foundation for the generator. Instead of having to manually writing (and maintaining) the source as a string to then parse into a syntax tree to verify output? I mean it can generate on compile time, so why not at test? :D
We just shipped prerelease builds of core framework (3.0.0-pre.15) and analyzers (1.23.0-pre.3).
This is a major version update with breaking changes. Check the release notes for more information.
https://xunit.net/releases/v3/3.0.0-pre.15
https://xunit.net/releases/analyzers/1.23.0-pre.3
We just shipped core framework v3 2.0.3, analyzers 1.22.0, and Visual Studio adapter 3.1.1.
Check the release notes for new features and bugs fixed.
https://xunit.net/releases/v3/2.0.3
https://xunit.net/releases/analyzers/1.22.0
https://xunit.net/releases/visualstudio/3.1.1
