如何在模拟中避免使用接口？

一分耕耘，一分收获！既然都打开这篇《如何在模拟中避免使用接口？》，就坚持看下去，学下去吧！本文主要会给大家讲到等等知识点，如果大家对本文有好的建议或者看到有不足之处，非常欢迎大家积极提出！在后续文章我会继续更新Golang相关的内容，希望对大家都有所帮助！

我试图避免使用接口，因为我的用例不需要它（类似地在 https://www.ardanlabs.com/blog/2016/10/avoid-interface-pollution.html 中提到）。但是，要创建模拟（使用 testify），我不需要一个模拟接口吗？我可以创建一个，但看起来很乏味。使用我的代码的所有地方都需要编写接口来进行模拟，而不是实际使用。有解决办法吗？

解决方案

如果接口的唯一可能用途是用于测试，我同意，这可能是一个糟糕的接口，您应该避免这样做。

最好的方法是重构您的系统，使其依赖于小型、有用的接口，而不是过于复杂的结构的一次性“模拟”。 net.Listener 接口就是一个很好的例子。是的，构建在 net.Listener 之上的系统很容易模拟，但这不是您实现 net.Listener 的原因。您使用该接口是因为它允许您交换许多种可能的实现，其中之一恰好用于测试。

另一个强大的方法是将函数链接在一起，而不是将功能硬编码为方法。 http.HandlerFunc 就是一个很好的例子，它也展示了出色的界面设计。查看许多“点击在一起”函数，它们返回 http.Handler，而不是一个巨大的“Handler”结构，然后您必须模拟该结构以进行测试。在我看来，这是 Go 的最佳状态。

请记住，函数在 Go 中是一流的，您可以通过传递和返回函数而不是将它们绑定到接口来获得很大的灵活性。当您这样做时，您还可以将它们捆绑在一起作为一个结构。这可以提供大量的功能，而这些功能对于测试也很有用。例如，请参阅 tls.Config，它允许您包含自己的 GetCertificate 函数（等等）。但是 tls.Config 结构也有合理的默认值，因此您不必每次都配置每个部分。通过传递 tls.Config 的专用版本，您可以测试 TLS 功能，而无需“模拟”任何内容。

这里的一致主题是让您的系统在实现方面变得灵活，并且作为一个很好的副作用，它使测试变得更容易。根据我的经验，这是比模拟更好的思考问题的方法。

您需要一个接口来模拟，因为模拟是您的第二个实现，所以如果您'如果您在单元测试中使用模拟，那么您的用例确实需要它。该接口充当占位符，填充该功能的某些实现。您计划至少有两种这样的实现：一种是模拟，一种是生产。为了能够互换使用它们进行测试，您必须使用接口。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《如何在模拟中避免使用接口？》文章吧，也可关注golang学习网公众号了解相关技术文章。