Why not AutoFixture?

[zvirja]

Hey 😊

Nice to meet you, another NSubstitute maintainer 😉

Why not to use AutoFixture? It seems to do exactly same thing. AutoFixture has a brilliant integration with NSubstitute and I created soo many projects with it - it works.

Have you found some limitations of the AutoFixture?

[Romfos]

Hello,

AutoFixture is a great library and this library is inspired by AutoFixture. I would recommend to continue to use AutoFixture if it suite your needs.

Problem with AutoFixture is that it is very poor supported and outdated for my needs.
Latest version was release 2 years ago. Version 5 in development 4~5 years and still not done.
Feature that required for me are out of scope for v5 and even release date for v5 is still unclear.
AutoFixture definitely need more love from contributor

I think that world changed for last 8 years, since firs v4 release:

In modern dotnet world most of the developers are using .NET rather then .NET Framework.

As the result:

1. Target modern .NET should be supported as a first priority
2. zero (or minimal count of) dependencies for modern dotnet. (for .NET Framework support could include extra dependencies as compromise)
3. out of the box support for modern dotnet types likes Immutable collections, Frozen collections, IAsyncEnumerable, TimeOnly, DateOnly, e.t.c
4. NRE should be enabled
5. No dependencies on vulnerable libraries

New challenges in 2025 like AOT, Trimmed apps

I know that microsoft sometime ago release preview of package
https://devblogs.microsoft.com/dotnet/testing-your-native-aot-dotnet-apps/

AutoFixture is not trim-friendly and aot-friendly (NSubstitute also is not trim and aot friendly.)

How to test such apps? =)

[zvirja]

Yeah, I see! Hope one day I (or somebody else) get a bit of inspiration and actually fix AutoFixture and implement all the missing specimen builders.

AutoFixture core is way more bloated that your fixture. Nice to see how much easier code could be if you follow simpler design 😉