具有复杂参数的单元测试答案

【问题标题】：Unit Testing with Complicated Parameters具有复杂参数的单元测试
【发布时间】：2012-08-06 05:24:36
【问题描述】：

假设我有一个方法：

someMethod(X anObject)

其中 X 是一种极其复杂的对象。我的意思是它不是一个可以轻易地即时实例化的东西。我需要以某种方式对 someMethod 进行单元测试，但我不能这么简单地创建一个 X 对象作为参数放入。

所以我首先想尝试模拟对象，但我遇到的问题是 someMethod 函数调用了 anObject 的许多方法，这意味着正在模拟的这个 X 对象有大量需要调用的函数，因此需要模拟预期。更糟糕的是，这些被调用的 X 对象方法返回更多的 X 对象，这意味着我必须模拟对象，期待模拟方法调用，返回更多的模拟对象。

关于这种情况，我有几个问题，因为我是单元测试概念的新手：

撇开冗长的单元测试方法不谈，我发现我的单元测试不仅要测试方法是否有效，还要指定实现（因为我基本上是在指定大部分被调用的代码）具有模拟期望的方法本身）。这是一个问题吗（主要是单元测试本身的概念）？
有没有什么办法可以解决这个问题，即使只是让我的单元测试方法更简洁、更易于维护？
我考虑从其他地方获取一个序列化的 X 对象，保存它，然后每当我调用我的单元测试方法时，我都会反序列化我的 X 对象并将其作为参数运行。这只是我脑海中突然想到的一些想法；真的有人这样做吗？

如果有人想知道我到底在做什么，我将使用IDebugContextListener 接口在 java 调试器的给定步骤中获取有关堆栈帧上数据的调试信息。我所指的“X”是由接口here定义的对象，包括IValue、IVariable和IStackframe等对象。所有这些变量都是 Java 调试器在运行时提供给我的。

【问题讨论】：

标签： java unit-testing mocking easymock

【解决方案1】：

您遇到这种困难的事实是设计问题的征兆。当某些东西难以测试时，重构直到它不难测试。

如果一个对象需要调用另一个对象的方法太多，那么封装很差，职责也很差。据推测，没有遵循单一职责原则。如果代码调用返回对象的方法，并且必须依次调用这些方法，则不遵循得墨忒耳法则。

【讨论】：

感谢您的回复；让我再解释一下我的对象。我有一个参数 X 和一个方法 parseX(X)，其唯一目的是以某种方式解析 X 内部的数据以返回。 X 很复杂，因此需要大量的方法调用，但我的函数只负责一项职责。至于demeter法则，一个IStackFrame对象（即X）有IVariables，它有IValues，需要调用sendMessage()返回更多IValues，需要调用toString()得到一个表示数据的可用字符串（5行代码）。真的需要更多的方法吗（对于 1 个衬垫）？
从某种意义上说，您可以在没有它们的情况下进行测试，因此不需要额外的方法。您可以创建要返回的模拟对象，然后模拟返回这些对象的方法。听起来它会很丑陋，难以阅读，而且难以维护。为了使代码更易于测试，您可能需要额外的方法。在进行该更改时，其他有益的更改可能会变得显而易见，而这些更改可能涉及排除其他方法。

【解决方案2】：

你的痛苦来自于你的方法不符合单一职责原则。你的方法用 X 做了很多事情——而且 X 听起来也太复杂了。这使得测试变得非常困难——即使是模拟。

将您的方法分解为可管理的块，每个块只做一件事。

【讨论】：