使用自动模拟容器是好的做法还是坏的做法？

Question

我最近一直在做一个项目，这个项目已经开始变得相当依赖，并且一直在探索使用AutoMocking容器来清理我的测试，使它们不那么脆弱的想法。

我听过TDD/BDD纯化论者反对使用它们的争论，比如:测试对象需要哪些依赖项并不是一目了然的，或者您可以添加不真正需要的依赖项。这两个理由听起来都不是反对使用它们的特别有力的理由。

从我的角度来看，引入一个将允许我根据需要进行重构，根据业务需求删除和引入依赖项，而不必总是返回到测试并引入新的mock/stub来编译代码。

AutoMocking被认为是一种好的/坏的实践吗？是否存在应该或不应该使用它的特定情况？

Answer 1

与任何工具或流程一样，使用它们也有正确的时机和错误的时机。没有什么是灵丹妙药。你必须问自己“这能帮助我完成我的工作吗？”归根结底，我们的工作是提供最大的商业价值。

在进行新开发时，自动锁定并不是很有帮助。一切都是从头开始开发的，TDD/BDD技术和“传统的”模仿工作得很好。从理论上讲，依赖关系并没有发生那么大的变化，当它们发生变化时，知道什么时候破坏了东西可能是很好的。

当处于维护模式(或处理遗留代码库)时，自动锁定可以证明是非常有益的。例如，您的任务是清理技术债务。这可能会涉及很多重构，并且能够将您的测试与这些更改隔离开来是一个巨大的时间节约。请记住，如果您的代码有很多依赖项，它可能会破坏SOLID和SOC，并且您将(或者至少应该)有许多测试没有利用所有的依赖项。所以在这种情况下自动锁定是非常有益的。当然，还有许多其他的例子也有帮助。

与任何工具一样，您必须确保它不会成为拐杖。利用自动锁定，您可以随意更改接口和apis，这显然是一种反模式。但如果使用得当，我发现它对我们的项目团队来说是一个巨大的好处。

它只需要批判性的思考和在正确的场景中的应用。

Answer 2

手动连接您的依赖关系(请记住，在单元测试中，您的依赖关系应该是针对非常少量的subject对象(一个))可以让您知道何时有异味-这个类太大了，应该被削减。也就是说，我不认为自动模仿是不好的，但就像每个工具一样，应该谨慎使用。

Answer 3

只有在依赖项开始嗅到的那一点，自动模拟才开始有用。Skimedic的答案和levelnis的评论都指向相同的方向。因此，这种做法通常应该避免，除非在无法摆脱遗留/技术债务的情况下。即使在其中一些情况下，我认为表现得像不存在自动模拟可能会更好，让团队速度的降低成为迫使管理层考虑某种重构的另一个理由；或者，如果这是一些不可避免的遗留问题，那么编写你自己的假构建器；与简单地使用自动模拟和简单的测试相比，测试的增加的复杂性将是一个更好的“危险区域”标志。

而且，IMO，您根本不应该在新代码中使用它。