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