5

可以说我有一个方法：

someMethod(X anObject)

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

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

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

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

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

4

2 回答 2

6

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

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

于 2012-08-06T05:39:16.760 回答
0

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

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

于 2012-08-06T09:42:44.780 回答