Autofixture: AutoFixture 的下一步是什么？

@Kralizek ，谢谢你的提问。

我只能为自己说话，实际上（仍然）正如我在https://github.com/AutoFixture/AutoFixture/issues/703#issuecomment -275347457 中所写：

我很好，如果我有必要的知识来审查 PR(s)。 通常，我（愉快地）回顾我之前工作、创建或贡献的代码库部分。

如果我错过了明确提到我的拉取请求或问题，请告诉我。 自从有人将我添加为审阅者或在问题上明确提及我以来已经有一段时间了...

谢谢@moodmosaic指出#703。 我的立场仍然和当时一样：我退出了 AutoFixture 项目，尽管如果明确调用我很乐意提供建议。

我认为如果似乎什么都没有发生，那么打开这个问题是有意义的。 可能是当前的维护者也可能继续前进。 让我们看看我们是否得到了他们中的任何一个的回应。 如果没有，请再 ping 我一次，我们应该说，一个星期左右？

我仍然可以帮助回顾我曾经经历过的领域的偶尔 PR，但我想这些领域可能在这些天之间很少而且相距甚远。

如果事情没有进展，让我们看看我们是否可以找出原因，然后看看我们是否可以在必要时帮助找到更多的人来提供帮助。

我不打算收回对项目的控制权，但据我所知，我仍然拥有对存储库的写入权限。 如果其他人自愿领导该项目，我将很乐意帮助实现这一目标。

嗨，大家好！

这里也缺少我的反馈。 不是正式的，但可能有人期望我目前是该项目最活跃/主要的维护者。

最初，我对维护充满热情，几乎没有什么可以进一步改进的想法。 即使在今天，我也看到了一些有意义的事情，至少从维护的角度来看是这样（例如，放弃对 .NET Standard 1.x 的支持）。

最近我完全放弃了对这个项目的支持，我自己确定了一些原因。

免责声明：目的不是责怪任何人，所以不要个人理解。 相反，我只是想分享我自己的经验，这样我们就可以看看我们是否可以为此做些什么以及是否值得。

很难改变项目。

改变这个项目非常困难，因为我有强烈的感觉，每个人都试图保留马克留下的遗产。 除了马克会做的事情之外，没有尝试其他任何事情的自由。 几乎所有他没有亲自参与的 PR 都引用了马克 :)

在某个时候，我开始觉得在这里修改任何东西变得太难了。 它扼杀了我对这个项目的热情。

即使马克离开了，我个人仍然觉得项目的所有权仍然属于他。 在做出决定时，我感受到了很大的内部/外部压力，因为有机会暴力和野蛮地破坏马克精心制作的东西。 这种感觉有一部分是我自己创造的，但也有一些其他维护者贡献了这种印象。

可能这只是我的期望和现实的差异。 我认为我可以通过这个项目表达和尝试我的想法，它将是敏捷的、新鲜的和充满新功能的。 但实际上，它感觉就像是一个遗留项目，不允许您进行太多更改，因为无论如何事情都运行良好。

我承认我的一些建议可能并不理想，当然，我不像可敬的马克那样经验丰富。 但我们本可以在做出决定时更加自由，因此该项目更加活跃。

有点寂寞

当我加入这个项目时，我希望参与敏捷讨论，成为团队的一员，与他人交往。 不幸的是，由于时间和/或其他因素的运气，其他维护者没有过多地参与讨论，最终我开始觉得我一个人在这里。 我觉得其他维护者目前对这个项目没有太多时间/热情，所以最后我开始分享。

我现在没有积极使用 AutoFixture

目前我没有写很多后端代码，所以不要过多使用 AutoFixture。 我仍然非常喜欢这个项目，并且相信这个库是必须的。 但是因为我没有写太多的测试，所以我个人并不要求任何改变。

更进一步，我不介意参与项目生活并分享我的知识是否适用。 如果有需要，我也可以帮助代码/维护。 但不幸的是，此时此刻，我没有足够的热情和精力来担任主要维护者。 如果我们有任何我们信任且充满激情的候选人，我们绝对应该邀请他/她并成为维护者之一。

首先，我想向@AutoFixture/core 团队道歉，因为没有在 #703 讨论中回复您。 是的，这对我来说是一段忙碌的时光（现在仍然如此），但我并没有忙到无法回复。 我只是没有收到任何关于我提及的任何通知，我也没有想过要回顾讨论。 当我重新访问#703 时，我真的只是发现了它。 再次，我很抱歉。 😞

我对 AutoFixture 未来的立场与我在 2016 年表达的立场相同。 我相信 AutoFixture 相当稳定，而且已经有好几年了。 如果有人想把它带入不同的方向，我认为他们最好从头开始。 自动生成测试数据的概念是一个非常好的概念，而且 AutoFixture 肯定不是 .NET 平台上可以完成的_唯一_方式。

这并不是说 AutoFixture 没有错误。 我要说的是，维护的数量和范围足够小，可以继续由@AutoFixture/core 团队负责。

我们需要首席开发人员吗？ 开源的历史似乎表明，没有个人领导的项目最终将被放弃。 但是一组线索呢？

我说我们尝试使用当前模型向前推进减去指定的领导，看看它是如何进行的。

AutoFixture 就是这么好的一个项目，看到它慢慢消失会很伤心。

由于@zvirja是该项目最活跃/主要的维护者。 我相信他领导这个项目将如何发展是有意义的。 维护一个开源项目需要花费大量的精力和时间。 就我个人而言，我不介意捐赠以使这个项目顺利进行。 谢谢@zvirja

有人应该指出房间里的大象，我也可以。

这个线程看起来很像葬礼（或遗憾）

我相信我们（社区）应该更多地专注于寻找摆脱困境的方法，而不是四处道歉。
到目前为止，这个线程一直非常擅长指出问题（随意完成）：

1. 当前的维护者没有时间/对项目不感兴趣
2. 项目很难维护
3. 代码审查过于严格

现在我们可以列出我们可以采取的行动吗？

如果有人关心这是我对此的看法：

1. 接受新成员加入社区。 @Kralizek已经存在了一段时间，他可能是一个不错的候选人。 也许在@AutoFixture/core 旁边还有另一个团队？
2. 创建积压的问题，确定优先级，向社区寻求帮助
3. 放松代码审查。 如果他不断被前任所有者打耳光，他就无法获得项目的所有权。
   允许进行实验，也许创建一个额外的包AutoFixture.Experimental ，用于尚未确认进入库的核心版本的东西（如 Boost 用于标准 C++ 库）。

我同意@zvirja的观点，这个项目非常令人生畏。 大约两年前我发现了 AutoFixture，直到最近才有勇气提交 PR。
我相信还有其他人有同样的感觉。 使用该工具并希望看到它蓬勃发展的人们。

感谢@aivascu指着房间里的大象。

我同意你的分析，但我还有第四个选择（尽管我讨厌它）：一个新的分支，让其维护者可以自由移动和乱搞。

另外，感谢您将我的名字列在列表中，但不幸的是，我对图书馆的内部没有太多经验，我真的无法在它周围移动。

当涉及到用户体验时，我很乐意进行干预......

赞助/支持者计划如何激发维护项目的热情？
毕竟这是一个受欢迎的回购。

我在过去三年使用 AutoFixture 的两分钱：

我认为 AutoFixture 的品牌名称很棒。 这是一个很酷的名字。

它在 Stack Overflow 上很受欢迎。 [autofixture]有 506 个问题，而[xunit.net]有 801 个问题。它几乎与 .NET Core 的准官方测试框架一样受欢迎是相当了不起的，部分原因在于 Mark 的不懈奉献教学（并成为一名优秀的老师）。 而马克的博客就像是免费测试知识的源泉。

我觉得 AutoFixture 的 API 比较难学。

我喜欢的 AutoFixture 部分：

• 能够使用 Auto-Mocking Container 设计模式（可能是我作为工程师接触过的最强大的测试概念）。
• Fixture.Freeze太棒了
• AutoMoq 扩展允许为需要模拟的事物快速创建固定装置
• 能够自动生成实体对象图并测试我的通用存储库模式并保证我的实体框架存储库的端到端集成测试代码覆盖率。

我从不直接使用的 AutoFixture 部分：

• Fixture.Inject

我想要改进/扩展的部分 AutoFixture

• 请参阅我昨天创建的问题：#1179
• 能够将 Guid 的默认行为替换为带有更好的字符串的字符串，例如 Waffle 文本生成器。 我意识到你今天可以做到这一点，但如果 #1179 已经完成，那么我们可以使用自定义数据提供程序插入任意元素选择器。
• AutoFixture 很慢，并且没有使用现代技巧来加速表达式编译，就像 Maksim Volkau 的 DryIoC 项目使用 Maksim 的 FastExpressionCompiler https://github.com/dadhi/FastExpressionCompiler

我不喜欢的 AutoFixture 部分（大部分是次要的）：

• Fixture.CustomizeVisual Studio 智能感知总是无法正常工作。
• 编写自定义，以及为什么自定义方法不允许您注入自定义。 那种东西是巴洛克式的和烦人的，并创造了一个巨大的学习曲线。
• 定制和标本建造者和东西到处都是。 它杂乱无章。
• 一些奇怪的词汇
• 整个Do..Without设计模式很难习惯。 它有效，但它很冗长，对递归实体没有帮助。 为此，您需要特殊的行为来告诉 AutoFixture 创建已创建对象的哈希表。
• 常见任务没有简化语法
• 单片设计，需要深入了解内部结构才能解决问题。 你不能只使用零碎的东西。 您几乎必须观看 Mark 的 PluralSight 课程才能克服最初的学习曲线，或者与 AutoFixture 专家的开发人员合作，以了解 AutoFixture 为何如此出色。
• Mark 认为 AutoFixture 应该只生成“匿名值”的立场。 它创建了许多第三方代码编写来完成工作。 示例包括以下 StackOverflow 帖子：
  
  
  
  • Autofixture，创建字典列表带交替键
  
  
  • 如何仅在列表中的项目子范围内分配属性？
  
  
  • 如何创建始终在 AutoFixture 中设置预定义值的类列表？
  
  

我看到创新可能性的部分：

• 随着 C# 变得越来越实用（模式匹配、记录类型等），AutoFixture 在理想情况下会越来越像 F# 中的 FsCheck 和 Hedgehog。
• 如果 AutoFixture 能够从 FsCheck 中具体化一些 concolic 测试概念，例如 Arb 功能，那就太好了。
• 使用 RLCheck 中讨论的创新，允许工程师创建超级健壮、多样化的测试输入（Guid as string 是一个 hack！） https://www.carolemieux.com/rlcheck_preprint.pdf

我认为我在这里概述的一些问题是为什么微软不会在其对 .NET Core 的任何测试中使用 AutoFixture。

这听起来像一个实验叉可能是要走的路。 AutoFixture 是我所知道的为数不多的开源项目之一，它们在开发人员的日常广泛使用中，绝对可以从额外的功能和改进的易用性中受益，并且背后拥有高质量的代码库。 如果减轻对贡献和改变方向的担忧，我无法想象兴趣会很低，这就是主动分叉会做的事情。

这听起来像一个实验叉可能是要走的路。

你为什么想这么做？ 你必须维护那个叉子。 如果您愿意这样做，为什么不转而成为该存储库的维护者呢？

我会考虑创建一个新的 repo（或继续构建这个 repo）来引入上面讨论的 QoL 改进，而不是一个实验性的分支。

AutoFixture 有一个强大的 API，可以实现很多但会吓跑很多人。 大多数东西都可以作为简单的语法糖来介绍。

引入 QoL 改进

Renato ( @Kralizek )，QoL 代表什么？ 生活质量？

是的。

如果您愿意这样做，为什么不转而成为该存储库的维护者呢？

@ploeh如何成为存储库的维护者？ 有什么要求吗？
老实说，看看当前的维护者名单，有一些大的需要填补。
我想为 AutoFixture 做出贡献，甚至可能作为维护者（有一天），我相信还有其他人，但我想不是任何人都会被接受来维护一个如此受欢迎的存储库。

你为什么想这么做？ 你必须维护那个叉子。

我同意那句话。 当我最初提出一个实验包时，在这个线程中，我正在考虑一种方法来缓解@zvirja的问题，同时维护存储库。 该软件包将包含构建在 AutoFixture 核心之上的功能，而不是经过更改的分叉。 就像@Kralizek所描述的那样。
当然，理想情况下，不需要这样的包。 我认为我们应该解决的是人的问题，而不是技术问题。

我认为我们应该解决的是人的问题，而不是技术问题。

我不知道那是什么意思。 跟我们多说些。

我认为我们应该解决的是人的问题，而不是技术问题。

我不知道那是什么意思。 跟我们多说些。

我认为他的意思是 AutoFixture 需要忠诚的维护者，他们可以自由地进行创新，而不必担心破坏精美的艺术品，正如@zvirja在他的评论中所说的那样。

如果你觉得自己的双手被以前的决定和领导力所投下的阴影束缚住了，那么你很难对它做出承诺。

很少有有趣的想法被拒绝，因为它们与“旧方式”相冲突。 这会扼杀任何人的动力。 从这个角度来看，叉子会释放很多这样的包袱。

好的，我是一个简单的人，我只想合并https://github.com/AutoFixture/AutoFixture/pull/928之类的东西。 正如我上面提到的，AutoFixture 没有很好的方法来支持生成唯一值。 乘法线性同余生成器似乎是此类功能的良好基础。 我们最近写了自己的，不如知道这个技巧的人聪明，后来我才找到 PR。

我想，“是的，让我们做更多这些很酷的事情。”

如何成为存储库的维护者？

你基本上表明你愿意承担这个责任。 据我所知，我仍然拥有存储库的管理员权限，尽管当前的维护者都没有明确说明这一点，但我的印象是他们都不会继续推进这一点。

有什么要求吗？ 老实说，看看当前的维护者名单，有一些大的需要填补。

不要担心过去。 现在，如果我正确地阅读了情况，AutoFixture 已经死了。 除非有人承担起推进它的任务，否则什么都不会改变。

因此，你可以犯世界上所有的错误，而且你几乎不会让事情变得更糟。

@ploeh如果您这样说，那么我很乐意成为维护者，我希望其他人也能挺身而出。

@aivascu谢谢，太好了。

我会给当前的维护者和闲逛者@zvirja 、 @moodmosaic 、@ adamchester 、@ ecampidoglio大约 24 小时对此发表评论，如果我没有看到任何抗议，我会给你维护者的权利。

@ploeh我这边没有异议。
@aivascu欢迎加入。 希望这个项目能给你带来你正在寻找的乐趣😊

@aivascu我不是维护者，但我喜欢这个库。 如果您需要有人来反映您的想法，请联系我。

@ploeh ， @aivascu ，我很好:+1: :rocket:

我很高兴讨论我工作、创建或贡献的部分代码库。 如果我错过了提到我的拉取请求（或问题），请告诉我。

@aivascu我向你致以最良好的祝愿。 我唯一的建议是，代码库中每 20,000 行代码可能需要大约 6 个月的时间，尤其是在一个地方没有明确的“架构决策记录”的情况下。 出于这个原因，在我维护的项目中，我开始编写这些以便人们理解代码的“风格”。 Mark 已经写了这些，但主要是在他的博客和/或 StackOverflow 上。 @moodmosaic也做了同样的事情。 我想说，接下来，在 repo 根目录中创建一个adr文件夹，记录任何设计原理。 您可以为此使用 .md 文件。 对于复杂的表，使用 html 表而不是 markdown 表。

谢谢大家的热烈欢迎。
我想一开始，我将听取@jzabroski的建议，并开始填补文档中的空白，以使新维护者和贡献者的入职更加容易。
同时，也许我可以开始处理现有的积压工作。
希望会有更多的社区成员站出来发扬光大，这个了不起的工具。

恭喜@aivascu。

我觉得你现在是首席开发人员。 我这么说是因为我觉得一旦你停下来，事情就会回到现在的“死”状态——所以我现在正在看着你:)

我希望 Autofixture 团队“寻找”新的团队成员，以减轻前面提到的孤独旅程问题的风险。 如果有人可以看看这个https://github.com/AutoFixture/AutoFixture/pull/1164，我很乐意贡献。

@aivascu我已经向您发送了加入核心 AutoFixture 团队的邀请，但该邀请仍在等待中。

@ploeh我刚刚接受了邀请。 谢谢！

@aivascu 👍 欢迎加入团队。

如果还有更多可以帮助您的事情，我会很高兴。 然而，我多年来一直在这个项目上不活跃，所以我不再知道任何实际的东西是如何工作的。 我希望@zvirja可以为您填写这些详细信息。

谢谢！

欢迎@aivascu

@aivascu我很乐意让您加入该项目。 如果您不介意，我会很高兴与您进行语音对话，这样我就可以展示所有内容并回答问题。 如果你愿意，请给我写一封邮件（你可以在提交中找到地址），以便我们就细节达成一致。

并再次欢迎。

@zvirja那真是太好了。 我会给你发一封电子邮件。

欢迎@aivascu :+1:

欢迎加入，@aivascu！ 🙂

@aivascu鉴于您作为一个充满激情和精力的新维护者来处理此问题，我们是否应该关闭并取消固定此问题？ 有点说现在我们的未来已经确定？ 😄

@zvirja我有点希望其他人可能会要求填补维护者的行列。 😄

如果有人觉得他/她可能喜欢成为此存储库的维护者，请打开问题或给我们留言。
我现在将关闭这个问题。