我最近一直在做一个项目，该项目已经开始变得相当依赖，并且一直在探索使用 AutoMocking 容器来清理我的测试并使其不那么脆弱的想法。
我听说过 TDD/BDD 纯粹主义者反对使用它们的论点，例如：测试对象需要哪些依赖项并不是很明显，或者您可以添加您并不真正需要的依赖项。听起来都不是反对使用它们的特别有力的论据。
从我的角度来看，引入一个可以让我根据需要进行重构，根据业务需求删除和引入依赖项，而无需不断地返回测试并引入新的模拟/存根来编译代码。
AutoMocking 被认为是一种好/坏的做法吗？是否存在应该使用或不应该使用的特定情况？
与任何工具或过程一样，使用它们有正确的时间和不正确的时间。没有什么是银弹。你必须问自己“这会帮助我完成工作吗？” 归根结底，我们的工作是提供最大的商业价值。
在进行绿地开发时，自动模拟没有那么有用。一切都是从头开始开发的，带有“传统”模拟的 TDD/BDD 技术效果很好。从理论上讲，依赖关系并没有发生太大的变化，当它们发生变化时，知道什么时候破坏可能会很好。
当处于维护模式（或处理遗留代码库）时，自动模拟可以证明是非常有益的。例如，您的任务是清理技术债务。这可能会涉及大量重构，并且能够将您的测试与这些更改隔离开来可以节省大量时间。请记住，如果您的代码有很多依赖项，它可能会破坏 SOLID 和 SOC，并且您将（或至少应该）进行许多不使用所有依赖项的测试。所以在这种情况下自动模拟是非常有益的。当然，还有许多其他例子也有帮助。
与任何工具一样，您必须确保它不会成为拐杖。利用 automocking 可以随意更改接口和 api 显然是一种反模式。但是如果使用得当，我发现它对我们的项目团队来说是一个巨大的好处。
它只需要在正确的场景中进行批判性思考和应用。
手动连接您的依赖项（并记住在单元测试中您的依赖项应该针对极少数主题对象（一个））让您知道什么时候有异味 - 这个类太大了，应该减少。也就是说，我认为自动模拟并不坏，但就像每个工具都应该谨慎使用。
仅在依赖项开始产生气味的那一刻，自动模拟就开始有用了。Skimedic 的回答和 levelnis 的评论都指向同一个方向。因此，一般应避免这种做法，除非在您无法摆脱遗留/技术债务的情况下。即使在其中一些情况下，我认为最好表现得像不存在自动模拟一样，让团队速度的下降成为迫使管理层考虑进行一些重构的另一个原因；或者，如果它是一些不可避免的遗产，那就编写你自己的假建造者；与简单地使用自动模拟和看似简单的测试相比，增加的测试复杂性将是“危险区域”的更好标记。
而且，IMO，您根本不应该在新代码中使用它。