Autofixture: What's next for AutoFixture?

@Kralizek, thank you for asking.

I can only speak for myself, it's actually (still) as I wrote in https://github.com/AutoFixture/AutoFixture/issues/703#issuecomment-275347457:

Fine by me, if I have the required knowledge to review the PR(s). Usually, I (happily) review parts of the code-base where I have previously worked on, created, or contributed.

If I missed a pull request or issue where I was explicitly mentioned, please let me know. It has been a while though since someone added me as a reviewer, or explicitly mentioned me on issue(s)...

Thank you, @moodmosaic, for pointing back to #703. My position is still the same as back then: I'm out of the AutoFixture project, although I'm happy to help with advice if explicitly invoked.

I think that it makes sense to open this issue if nothing seems to be happening. It may be that the current maintainers may have moved on as well. Let's see if we get a response from any of them. If not, please ping me again in, should we say, a week or so?

I can still help review the occasional PR in areas I’ve had experience with, but I guess those areas are probably few and far between these days.

If things aren’t moving, let’s see if we can figure out why, and then see if we can help find more people to help if necessary.

I don't intend to take back control of the project, but as far as I can tell, I still have write access to the repository. If someone else volunteers to lead the project, I'll be happy to help make that happen.

Hi guys!

There is also my feedback missing here. Not officially, but probably there are expectations that I was a most active/lead maintainer for the project for now.

Initially I've been very passionate about maintenance and had few ideas what could be improved further. Even today I see things which it makes sense to do, at least from the maintenance perspective (e.g. drop .NET Standard 1.x support).

Recently I stepped back from supporting the project at all and I self-identified a few reasons for this.

DISCLAIMER: The purpose is not to blame anybody, so don't get it personally. Rather, I just want to share my own experience so we could see whether there is anything we can do about that and whether it worth it.

It's difficult to change the project.

It's very difficult to change this project, as I have strong feeling that everybody tries to preserve the legacy Mark left. There is no freedom to try anything else, except of what Mark would do. Mark was cited in almost every PR where he didn't participate in person :)

At some point I started to feel that I it became too difficult to modify anything here. And it killed the passion I had about the project.

Even though Mark left, I still personally feel that the ownership of the project still belongs to him. I feel a lot of internal/external pressure when making the decisions, as there is a chance to violently and barbarically break something which was so nicely crafted by Mark. Some of this perception was created solely by me, but there are parts when other maintainers contributed to make such an impression.

Probably it's just the difference with my expectations and reality. I though that I would be able to express and try my ideas with this project, that it will be agile, fresh and full of new features. But in reality it felt like a legacy project where you are not allowed to change a lot, as things are working just fine anyway.

I admit that some of my proposals could have been not ideal and, of course, I'm not such experienced as honorable Mark. But we could have be more free in decisions we made, so the project is more alive.

It's a bit lonely

When I joined the project, among others I expected to participate in agile discussions, be a part of the team, socialize with others. Unfortunately, due to luck of time and/or other factors other maintainers didn't participate too much in the discussions and eventually I started to feel that I'm alone here. I feel that other maintainers don't have too much time/passion about this project at the moment, so finally I started to share the same.

I'm not working actively with AutoFixture right now

At the moment I'm not writing a lot of back-end code, so don't use AutoFixture too much. I'm still a huge fun of the project and believe that this library is a must have. But because I'm not writing too much tests, I don't personally demand any changes.

Going further I don't mind to participate in the project life and share my knowledge whether applicable. If there is a need, I could help with the code/maintenance as well. But at this moment, unfortunately, I don't have passion and energy enough to be a lead maintainer. If we have any candidate for that who we trust and who is full of passion, we should definitely invite him/her and make one of the maintainers.

First, I want to apologize to the @AutoFixture/core team for not getting back to you in the #703 discussion. Yes, it was a busy time for me (and still is) but I wasn't so busy that I couldn't reply. I simply didn't get any notifications for any of my mentions and I didn't think to check back on the discussion. I literally just found out about it now as I revisited #703. Again, I'm sorry. 😞

My position on the future of AutoFixture is the same one I expressed back in 2016. I believe AutoFixture is pretty stable and has been for years now. If someone wants to take it into a different direction, I think they would be better off starting from a clean slate. The concept of auto-generating test data is a very good one and AutoFixture surely is not the _only_ way it could be done on the .NET platform.

That's not to say that AutoFixture is bug-free. What I'm saying is that the volume and scope of the maintenance is small enough that it can remain the responsibility of the @AutoFixture/core team.

Do we need a lead developer? The history of open source seems to suggest that a project without an individual lead will eventually be abandoned. But what about a group of leads?

I say we try to move forward with the current model minus an appointed lead and see how it goes.

AutoFixture is such a good project, it will be very sad to see it slowly fade away.

Since @zvirja is the most active/lead maintainer of the project. I believe it make sense for him to lead how this project will evolve. Maintaining a open source project takes a lot of effort and time. Personally I do not mind donating to make this project going. And Thank you @zvirja

Someone should point out the elephant in the room, so might as well be me.

This thread looks a lot like funeral (or a regretrospective)

I believe we (the community) should focus more on finding a way out of the situation we found itself in than throwing apologies around.
So far this thread has been very good at pointing out the problems (feel free to complete):

1. The current maintainers have no time/are not interested in the project
2. The project is hard to maintain
3. Code review is too restrictive

Now can we come up with a list of actions we can take?

If anyone cares here's my take on this:

1. Accept new members into the community. @Kralizek has been around for a while, he might be a good candidate. Maybe have another team alongside @AutoFixture/core?
2. Create a backlog of issues, prioritize, ask the community for help
3. Loosen-up the code review. One can't take the ownership of a project if he's constantly being slapped on the hands by the previous owner.
   Allow for experiments, maybe create an additional package AutoFixture.Experimental, for the stuff, that's not yet confirmed to get to the core version of the library (like Boost is for the standard C++ library).

I agree with @zvirja, the project is very intimidating. I have discovered AutoFixture around two years ago and only recently got the courage to submit a PR.
I believe there are others that feel the same way. People that are using the tool and would like to see it thrive.

Thanks @aivascu for pointing at the elephant in the room.

I agree with your analysis but I would also had a fourth option (although I would hate it): a new fork to give its maintainers freedom to move and mess around.

Also, thanks for putting my name in the list but unfortunately I am not so experienced with the internals of the library and I really can't move myself around it.

I can gladly intervene when it comes to the user experience...

How about a sponsorship/backer program to whip up some enthusiasm for maintaining the project?
It is a popular repo after all.

My two cents using AutoFixture the last three years:

I think the brand name for AutoFixture is great. It's a cool name.

It's popular on Stack Overflow. [autofixture] has 506 questions, whereas [xunit.net] has 801. For it to be almost as popular as the quasi-official testing framework of .NET Core is rather remarkable, and in part due to Mark's relentless dedication to teaching (and being a great teacher). And Mark's blog is like a fount of free testing knowledge.

I think the API of AutoFixture is rather difficult to learn.

Parts of AutoFixture I love:

• Ability to use Auto-Mocking Container design pattern (probably the most powerful testing concept I've been introduced to as an engineer).
• Fixture.Freeze is amazing
• AutoMoq extension to allow quickly creating fixtures for things that require a mock
• Ability to automatically generate an entity object graph and test my generic Repository pattern and guarantee end-to-end integration test code coverage for my Entity Framework repositories.

Parts of AutoFixture I never use directly:

• Fixture.Inject

Parts of AutoFixture I want improved/extended

• See my issue created yesterday: #1179
• Ability to swap out the default behavior of Guids for strings with something nicer, like Waffle Text Generator. I realize you can do this today, but if #1179 were worked on, then we could plug in Arbitrary Element Pickers with a custom data provider.
• AutoFixture is slow, and uses no modern tricks to speed-up expression compilation, like Maksim Volkau's DryIoC project does with Maksim's FastExpressionCompiler https://github.com/dadhi/FastExpressionCompiler

Parts of AutoFixture I don't love (mostly minor):

• Fixture.Customize always works incorrectly with Visual Studio intellisense.
• Writing customizations, and why Customize method doesn't let you inject a customization. That sort of stuff is baroque and annoying and creates a huge learning curve.
• Customizations and speciman builders and things are all over the place. It's disorganized.
• Weird vocabulary for some things
• The whole Do..Without design pattern is rather difficult to get used to. It works, but it's verbose and doesn't help you with recursive entities. For that, you need special Behaviors to tell AutoFixture to create a hash table of already created objects.
• No simplified syntax for common tasks
• Monolithic design that requires deep understanding of the internals just to solve problems. You can't just use bits and pieces. You have to pretty much watch Mark's PluralSight course just to get past the initial learning curve, or work with a developer who is an expert in AutoFixture, in order to appreciate why AutoFixture is so awesome.
• Mark's stance that AutoFixture should only generate "anonymous values." It creates a lot of third-party code writing to get stuff done. Examples include the following StackOverflow posts:
  
  
  
  • Autofixture, create a list of dictionary with alternating key
  
  
  • How do I assign a property on only a subrange of items in a list?
  
  
  • How do I create a list of classes which always have a predefined value set in AutoFixture?
  
  

Parts I see possibility for innovation:

• As C# becomes more and more functional (pattern matching, record types, etc), AutoFixture would ideally work more and more like FsCheck and Hedgehog in F#.
• It would be nice if AutoFixture was able to reify some concolic testing concepts from FsCheck, like the Arb feature.
• Use innovations like those discussed in RLCheck to allow engineers to create super robust, diverse test inputs (Guid as string is a hack!) https://www.carolemieux.com/rlcheck_preprint.pdf

I think some of the issues I outline here are why Microsoft won't use AutoFixture in any of its tests for .NET Core.

It sounds like an experimental fork could be the way to go. AutoFixture is among the few open source projects I know of that is both in widespread everyday use by developers, can definitely benefit from additional capabilities and improved ease of use, and has a high quality codebase behind it. I can't imagine interest would be low if concerns over contributing and changing direction were mitigated, which is what an active fork would do.

It sounds like an experimental fork could be the way to go.

Why would you want to do that? You'd have to maintain that fork. If you're willing to do that, why not step up as a maintainer of this repository instead?

Rather than an experimental fork, I'd consider create a new repo (or keep building on this one) to introduce the QoL improvements were discussed above.

AutoFixture has a powerful API that can achieve a lot but can scare off a lot of people. Most things can be introduced as simple syntactic sugar.

to introduce the QoL improvements

Renato (@Kralizek ), what does QoL stand for? Quality of Life?

Yep.

If you're willing to do that, why not step up as a maintainer of this repository instead?

@ploeh how does one step up as a maintainer for the repository? Are there any requirements?
To be honest looking at the current list of maintainers, there are some big shoes to fill.
I'd like to contribute to AutoFixture, maybe even as a maintainer (one day) and I'm sure there are others, but I imagine it's not anyone that would be accepted to maintain a repository this popular.

Why would you want to do that? You'd have to maintain that fork.

I agree with that quote. When I initially proposed an experimental package, in this thread, I was thinking of a way to mitigate the issues @zvirja had, while maintaining the repository. The package would have contained features built on top of the AutoFixture core, not an altered fork. Something like what @Kralizek described.
Of course, ideally, a package like this would not be needed. What I think we should solve is the people problem rather than a technology problem.

What I think we should solve is the people problem rather than a technology problem.

I don't know what that means. Tell us more.

What I think we should solve is the people problem rather than a technology problem.

I don't know what that means. Tell us more.

I think what he means is that AutoFixture needs committed maintainers that feel free to innovate without fear of destroying a beautiful piece of art, as for what @zvirja said in his comment.

It's hard to feel committed to something where you feel your hands are tied by the shadow cast by previous decisions and leadership.

Few interesting ideas were turned down because they were conflicting to the "Old Ways". This would kill anybody's motivation. From that point of view, a fork would free up a lot of this baggage.

OK, I'm a simple guy, I just want stuff like https://github.com/AutoFixture/AutoFixture/pull/928 merged. As I mentioned above, AutoFixture does not have good ways to support generating unique values. Multiplicative linear congruential generator seems like a good basis for such a feature. We recently wrote our own and was not as clever as somebody who knew about this trick, and I only found the PR later on.

I'm like, "Yeah, let's do more of this cool stuff."

how does one step up as a maintainer for the repository?

You basically state that you're willing to take on that responsibility. As far as I can tell, I still have admin rights to the repository, and although none of the current maintainers have explicitly stated the this, I get the impression that none of them are going to be carrying this forward.

Are there any requirements? To be honest looking at the current list of maintainers, there are some big shoes to fill.

Don't worry about the past. Right now, if I read the situation correctly, AutoFixture is dead in the water. Unless someone takes on the task to carry it forward, nothing is going to change.

Thus, you can make all the mistakes in the world, and you'll hardly make things worse.

@ploeh if you put it like this then I'd be happy to step up as a maintainer and I hope other will step up as well.

@aivascu Thank you, that's great.

I'll give current maintainers and hangarounds @zvirja, @moodmosaic, @adamchester, @ecampidoglio about 24 hours to comment on this, and if I don't see any protests, I'll give you maintainer rights.

@ploeh No objections from my side.
@aivascu Welcome on board. Hope this project will bring you fun you are looking for 😊

@aivascu I'm not a maintainer but I love this library. Just ping me if you need someone to bounce your thoughts.

@ploeh, @aivascu, fine by me :+1: :rocket:

I'm happy to discuss about parts of the code-base where I have worked on, created, or contributed. If I missed a pull request (or an issue) where I was mentioned, please let me know.

@aivascu My best wishes to you. My only advice is it can take about 6 months for every 20,000 lines of code in a codebase, especially if there is not some clear "architecture decision records" in one place. For this reason, on the projects I maintain, I've started writing those so people understand the "style" of the code. Mark has written these, but mostly on his blog and/or StackOverflow. @moodmosaic has done the same. I'd say, going forward, create an adr folder in the repo root that documents any design rationale. You can use .md files for that. For complex tables, use html tables rather than markdown tables.

Thank you all for the warm welcome.
I think for the beginning, I'm going to take the advice from @jzabroski and will start filling in the gaps in the documentation to make the on-boarding of new maintainers and contributors easier.
In parallel maybe I can start burning through the existing backlog.
Hopefully there will be more community members stepping up to carry forward, this amazing tool.

Congratulations @aivascu.

I feel you're the lead developer now. I am saying this, because I feel that things will go back to the 'dead' state they are now, as soon as you stop - so I am looking at you now :)

I hope Autofixture team 'hunts down' new team members, to mitigate the risk of the lonely journey issue mentioned before. I am happy to contribute only, if someone could take a look at this https://github.com/AutoFixture/AutoFixture/pull/1164.

@aivascu I've sent you an invitation to join the core AutoFixture team, but the invitation is still pending.

@ploeh I have just accepted the invitation. Thank you!

@aivascu 👍 Welcome to the team.

If there's more I can do to help you, I'll be happy to. I have, however, been inactive on the project for years, so I no longer know how any of the practical stuff works. I hope that @zvirja can fill you in on those details.

Thank you!

Welcome @aivascu

@aivascu I would be happy to onboard you to the project. If you don't mind I would be really happy to have a voice talk with you, so I can show everything and answer the questions. If you are up for that, please write me a mail (you can find address in commits) so we can agree on details.

And welcome again.

@zvirja that would be really nice. I will drop you an email.

Welcome @aivascu :+1:

Welcome onboard, @aivascu! 🙂

@aivascu Given that you stepped up as a new maintainer full of passion and energy to work on this, should we just close & unpin this issue? Kind of saying that for now our future is determined? 😄

@zvirja I was kinda hoping someone else might request to fill the ranks of maintainers. 😄

If anyone feels that he/she might enjoy being a maintainer for this repository open an issue or drop us a message.
I will be closing the issue now.