Question

我有一个连接其他三个服务的类，专门用于实现其他服务更加模块化，但我的单元测试逻辑的大部分是模拟验证。有没有办法重新设计以避免这种情况？

Python示例：

class Input(object): pass

class Output(object): pass

class Finder(object): pass

class Correlator(object): pass
  def __init__(self, input, output, finder):
    pass
  def run():
    finder.find(input.GetRows())
    output.print(finder)

然后我必须模拟输入，输出和查找器。即使我做了另一个抽象并从Correlator.run（）返回一些内容，它仍然需要作为模拟进行测试。

Answer 1

没有理由只使用单元测试 - 对于这种情况，集成测试可能更有用。正确初始化所有对象，稍微使用主类，并在（可能是复杂的）结果上断言。这样你就可以测试接口，输出可预测性以及其他重要的东西。我以前用过这个，发现难以集成测试的东西可能有太多属性/参数或太复杂/错误格式化的输出。

Answer 2

问问自己：在这个特定的测试用例中，您究竟需要检查什么？如果这个检查不依赖于其他不是假的类，那么你就可以了。

然而，很多模拟通常都是一种气味，你可能试图在没有实际集成的情况下测试集成。因此，如果你假设如果类通过了模拟测试，那么使用真实类就可以了，不是的，你必须再写一些测试。

就个人而言，我根本不会写很多单元测试。我是Web开发人员，我更喜欢功能测试，它通过HTTP请求测试整个应用程序，就像用户一样。你的情况可能不同

Answer 3

快速浏览一下，这看起来就像是模仿的程度变得很大。如果您使用的是动态语言（我假设您的示例是在Python中），我会尝试构建生产类的子类，其中包含最有问题的方法被覆盖并呈现模拟数据，因此您需要得到生产和模拟代码的混合。如果您的代码路径不允许实例化对象，我会在替换方法中尝试monkey patching返回模拟数据。

天气与否这是代码味道还取决于模拟数据的质量。根据我的经验，放入调试器并复制粘贴已知正确的数据或从网络中嗅探它是确保这一点的首选方法。

集成与单元测试也是一个经济的问题：用集成/功能测试替换单元测试有多痛苦？你的系统规模越大，轻量级嘲弄就越多，因此单元测试就越多。

有一个单元测试，主要是模拟验证气味？

3 个答案: