BarretApr 29

New post from my blog...

In case you missed it earlier...

Testing in .NET with xUnit + NSubstitute + Shouldly
https://barretblake.dev/posts/development/2026/04/testing-dotnet/ #testing #dotnet #xunit #nsubstitute #shouldly

BarretApr 29

New post from my blog...

Testing in .NET with xUnit + NSubstitute + Shouldly
https://barretblake.dev/posts/development/2026/04/testing-dotnet/ #testing #dotnet #xunit #nsubstitute #shouldly

Ernst Greiner 🇪🇺Apr 25

Oh Mann, ich schreibe gerade alles um von FluentAssertions auf Shouldly...

#dotnet #fluentassertions #shouldly

robrichFeb 28, 2025
https://github.com/kmtchl/FluentAssertionsToShoudlyConverter - Convert from #FluentAssertions to #Shouldly. Nice work https://github.com/kmtchl.
GitHub - kmtchl/FluentAssertionsToShouldlyConverter

Contribute to kmtchl/FluentAssertionsToShouldlyConverter development by creating an account on GitHub.

GitHub
Ernst Greiner 🇪🇺Feb 12, 2025

If you are "unhappy" with license changes in FluentAssertions since version v8.0, you can force it to stay on v7.x.

.NET (Core), project file:

<code>
<ItemGroup>
<PackageReference Include="FluentAssertions" Version="[7.0,8.0)" />
</ItemGroup>
</code>

.NET Framework, packages.config:

<code>
<packages>
<package id="FluentAssertions" version="7.0.0" allowedVersions="[7,8)" targetFramework="net48" />
</packages>
</code>

Or just use Shouldly in future projects...

hth

#FluentAssertions #Shouldly #NuGet #UnitTesting #dotnet

Show threadbitbonkJan 14, 2025
@svelmoe @ddoomen I think for us the biggest missing part is `Should().BeEquivalentTo()` for complex object graphs when migrating to @xunit Assert or #Shouldly
Show threadbitbonkJan 14, 2025
@svelmoe @ddoomen We are in exactly the same situation. The new licensing costs are just too expensive for us. Maybe there will be a good migration path to #Shouldly?