我有一个用于 android Log
的静态包装器类。
它看起来像这样(简化):
// Source: https://github.com/ccrama/Slide/blob/master/app/src/main/java/me/ccrama/redditslide/util/LogUtil.java
public class LogUtil {
private static final int CALLING_METHOD_INDEX;
static {
int i = 1;
for (StackTraceElement ste : Thread.currentThread().getStackTrace()) {
i++;
if (ste.getClassName().equals(LogUtil.class.getName())) {
break;
}
}
CALLING_METHOD_INDEX = i;
}
public static String getTag() {
final StackTraceElement ste = Thread.currentThread().getStackTrace()[CALLING_METHOD_INDEX];
return "(" + ste.getFileName() + ":" + ste.getLineNumber() + ")";
}
public static void v(String message) {
Log.v(getTag(), message);
}
}
我的问题:我正在测试另一个调用此方法的方法 LogUtil.v()
的方法。
如果可能的话,有没有办法用 Mockito 而不是 Powermock(ito) 来测试另一种方法?
目前它抛出一个 LogUtil.v not mocked
异常。
我读到如果我必须使用 PowerMockito,我做错了什么(=> 不遵循 TDD)。
最佳答案
(免责声明:我是那些告诉人们不要使用 PowerMock(ito) 的人之一)
话虽如此:当您使用无法更改的第 3 方库时,使用 PowerMock(ito) 可能是一个合理的选择。
本质上,您只有两个选择:
- 如前所述;选择允许模拟 static 方法的框架;并且允许您防止此类静态初始化代码在您的单元测试环境中执行。有 PowerMock(ito),还有 JMockit .
- 或者,您可以围绕这些类构建一个小型包装器;然后确保所有您自己的代码仅适用于这些包装器。
因此您必须评估这两种方法的优缺点;并选择对您和您的团队“效果更好”的那个。就我个人而言,总是选择选项 2。当然,这只有在编写新 代码时才有可能。
实际上,为了用您自己的包装器替换那些静态调用而对整个代码库进行大规模重构并不是一件轻松的事情。
关于java - 测试调用静态包装器方法的类,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/43783516/