Mockito 与 JMockit 之间的比较 - 为什么 Mockito 比 JMockit 更好？

发布于 2024-09-30 17:54:00 字数 606 浏览 9 评论 0原文

我正在调查我的项目使用哪个模拟框架，并将其范围缩小到 JMockit 和 Mockito。

我注意到 Mockito 被评为“最佳模拟框架Stackoverflow 上的 Java”。
比较 JMockit 的“模拟工具的功能比较矩阵”看起来JMockit有多个不同的功能。

是否有人对 Mockito 可以做什么而 JMockit 无法实现的事情有任何具体信息（不是意见），反之亦然？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

把梦留给海 2024-10-07 17:54:01

2019 年 9 月更新：唯一的 Spring Boot 支持（默认）的模拟框架是Mockito< /强>。如果你使用 Spring，答案就很明显了。

我想说竞争是在JMockit和PowerMock之间，然后是Mockito。

我会留下“普通”jMock 和 EasyMock，因为它们只使用代理和代理。 CGLIB 并且不像较新的框架那样使用 Java 5 工具。

jMock 也已经有 4 年多没有发布稳定版本了。 jMock 2.6.0 从 RC1 到 RC2 需要 2 年时间，然后又需要 2 年时间才真正发布。

关于代理和代理CGLIB 与仪器：

（EasyMock和jMock）基于java.lang.reflect.Proxy，
这需要一个接口
实施的。此外，他们
支持创建mock对象
对于通过 CGLIB 子类的类
一代。正因如此，说道
课程不能是最终的并且是唯一的
可重写的实例方法可以是
嘲笑。然而，最重要的是，
当使用这些工具时
被测代码的依赖关系（即
是，其他类的对象
正在测试的给定类
取决于）必须由控制
测试，以便模拟实例可以
传递给那些的客户
依赖关系。因此，依赖关系
不能简单地实例化为
客户端类中的新运算符
我们要编写单元测试。
最终，技术限制
传统模拟工具的强加
以下设计限制
生产代码：
在测试中可能需要模拟的每个类必须实现
一个单独的界面或不是最终的。
必须获取每个待测试类的依赖关系
通过可配置的实例创建
方法（工厂或服务
定位器），或者暴露依赖关系
注射。否则，单元测试将不会
能够通过模拟实现
对下单元的依赖关系
测试。
由于只能模拟实例方法，因此需要对类进行单元测试
无法调用任何静态方法
他们的依赖关系，也不实例化
他们使用任何构造函数。

以上内容复制自 http://jmockit.org/about.html 。此外，它在几个方面对自身 (JMockit)、PowerMock 和 Mockito 进行了比较：

现在还有其他模拟工具
Java也克服了
传统方法的局限性，
在它们之间 PowerMock、jEasyTest 和
模拟注入。最接近的那个
JMockit 的功能集是
PowerMock，所以我简单评估一下
它在这里（此外，另外两个是
更有限并且似乎不是
不再积极开发）。
JMockit 与 PowerMock
首先，PowerMock没有提供完整的mocking API，
而是作为一个扩展
另一个工具，目前可以是
EasyMock 或 Mockito。这显然是
对现有用户的优势
这些工具。
另一方面，JMockit 提供了全新的 API，尽管
它的主要API（期望）是相似的
EasyMock 和 jMock。虽然这
创建更长的学习曲线，它
还允许 JMockit 提供
更简单、更一致、更容易
使用API。
与 JMockit Expectations API 相比，PowerMock API 是
更加“低级”，迫使用户
找出并指定哪些类
需要准备测试（与
@PrepareForTest({ClassA.class,
...}）注释）并要求
具体的API调用来处理
各种语言结构
生产中可能存在的
代码：静态方法
(mockStatic(ClassA.class)),
构造函数
（抑制（构造函数（ClassXyz.class））），
构造函数调用
(expectNew(AClass.class))，部分
模拟（createPartialMock（ClassX.class，
“methodToMock”））等
有了 JMockit Expectations，各种方法和构造函数都可以
以纯粹声明的方式嘲笑，
通过指定部分模拟
@Mocked 中的正则表达式
注释或简单地“un-mocking”
没有记录的会员
期望；也就是说，开发商
只是声明一些共享的“模拟
测试类的“字段”，或者一些
“本地模拟字段”和/或“模拟
单独测试的参数”
方法（在最后一种情况下
@Mocked 注解通常不会
需要）。
JMockit 中提供的一些功能，例如对模拟的支持
equals 和 hashCode，被覆盖
方法和其他方法目前还没有
PowerMock 支持。另外，还有
没有与 JMockit 同等的能力
捕获实例并模拟
指定基数的实现
测试执行时键入，无需
测试代码本身有任何
了解实际实施情况
类。
PowerMock 使用自定义类加载器（通常每个测试类一个）
为了生成修改版本
被嘲笑的类。如此大量使用
自定义类加载器的数量可能会导致
与第三方库冲突，
因此有时需要使用
@PowerMockIgnore("package.to.be.ignored")
测试类上的注释。
JMockit 使用的机制（通过
“Java代理”）更简单、更安全，
虽然它确实需要通过
JVM 时的“-javaagent”参数
在JDK 1.5上开发；在 JDK 1.6+ 上
（它总是可以用于
开发，即使部署在
旧版本）没有这样的
要求，因为 JMockit 可以
透明地加载 Java 代理
使用 Attach API 请求。
另一个最近的模拟工具是
莫基托。虽然它不尝试
克服老年人的局限性
工具（jMock、EasyMock），确实如此
引入新的行为方式
使用模拟进行测试。 JMockit 也
支持这种另类风格，
通过验证 API。
JMockit 与 Mockito
Mockito 依赖对其 API 的显式调用来分离代码
记录 (when(...)) 和
验证（验证（...））阶段。这
意味着任何对模拟的调用
测试代码中的对象还需要
对模拟 API 的调用。
此外，这通常会导致
重复when(...) 和
验证（模拟）...调用。
对于 JMockit，不存在类似的调用。当然，我们有新的
NonStrictExpectations() 和 new
Verifications() 构造函数调用，但是
每次测试仅出现一次
（通常），并且完全
与调用分开
模拟方法和构造函数。
Mockito API 在使用的语法中存在一些不一致的地方
对模拟方法的调用。在
记录阶段，我们有类似的电话
当（mock.mockedMethod（args））...同时
在验证阶段同样的调用
将写成
验证（模拟）.mockedMethod（args）。
请注意，在第一种情况下
调用mockedMethod
直接在模拟对象上，而在
第二种情况是在
verify(mock) 返回的对象。
JMockit 没有这样的不一致，因为调用
总是创建模拟方法
直接在模拟实例上
他们自己。（只有一处例外：
匹配相同的调用
模拟实例，一个 onInstance(mock)
使用调用，导致代码如下
onInstance(mock).mockedMethod(args);
大多数测试不需要使用这个，
不过。）
就像其他依赖方法的模拟工具一样
链接/包装，Mockito 也运行
存根时语法不一致
无效方法。例如，你写
当(mockedList.get(1)).thenThrow(new
运行时异常());对于一个非空的
方法和 doThrow(new
RuntimeException()).when(mockedList).clear();
对于一个空的。有了 JMockit，就可以了
始终相同的语法：
模拟列表.clear();结果=新
运行时异常（）；。
在 Mockito 间谍的使用中还出现了另一个不一致之处：“mocks”
允许真正的方法是
在监视的实例上执行。为了
例如，如果间谍指的是空的
列出来，然后代替书写
当(spy.get(0)).thenReturn(“foo”)你
需要写
doReturn("foo").when(spy).get(0).和
JMockit，动态模拟功能
提供类似的功能
间谍，但从那以后就没有这个问题了
真正的方法只在期间执行
重播阶段。
在 EasyMock 和 jMock（第一个 Java 模拟 API）中，重点是
完全取决于预期的记录
模拟方法的调用，对于
（默认情况下）不存在的模拟对象
允许意外的调用。那些
API 还提供记录
允许调用模拟对象
确实允许意外调用，
但这被视为二等
特征。另外，通过这些
工具没有办法明确
验证对模拟的调用
测试中的代码已被执行。凡此种种
验证是隐式执行的
并且自动。
在 Mockito（以及 Unitils Mock）中，相反的观点是
采取。所有对模拟对象的调用
测试期间可能发生的情况，
无论是否记录，都允许，
从未预料到。验证是
在代码之后显式执行
测试中被执行，从不
自动。
这两种方法都过于极端，因此都不是最佳的。
JMockit 期望 &验证
是唯一允许的 API
开发者可以无缝地选择
严格（预期）的最佳组合
默认情况下）和非严格（允许
默认）每个的模拟调用
测试。
更明确地说，Mockito API 具有以下缺点。如果你
需要验证对a的调用
期间发生了非空模拟方法
测试，但测试需要
该方法的返回值是
与默认值不同
返回类型，然后是 Mockito 测试
将有重复的代码：a
当(mock.someMethod()).thenReturn(xyz)
在记录阶段调用，并且
验证（模拟）.someMethod() 在
验证阶段。使用 JMockit，严格
期待永远可以被记录，
这不必明确
已验证。或者，调用
计数约束（次= 1）可以是
为任何记录的非严格指定
期望（与 Mockito 这样
约束只能在a中指定
验证（模拟，约束）调用）。
Mockito 的按顺序验证和完整验证的语法很差
验证（即检查
所有对模拟对象的调用都是
明确验证）。在第一个
在这种情况下，需要一个额外的对象
创建，并调用验证
它： InOrder inOrder = inOrder(mock1,
模拟2，...）。在第二种情况下，调用
像 verifyNoMoreInteractions(mock) 或
验证零交互（模拟1，模拟2）
需要制作。
使用 JMockit，您只需编写 new VerificationsInOrder() 或 new
FullVerifications() 而不是 new
Verifications() （或新的
FullVerificationsInOrder() 进行组合
两项要求）。无需指定
涉及哪些模拟对象。不
额外的模拟 API 调用。并且作为一个
奖金，通过致电
unverifiedInvocables() 内
订购验证块，您可以
执行订单相关的验证
这在 Mockito 中根本不可能实现。
最后，JMockit 测试工具包
拥有更广泛的范围和更加雄心勃勃的目标
比其他模拟工具包的目标，在
为了提供完整且
复杂的开发人员测试
解决方案。一个很好的模拟 API，甚至
如果没有人为限制，则不是
足以进行富有成效的创造
测试。与 IDE 无关、易于使用、
以及集成良好的代码覆盖率工具
也是必不可少的，这就是
JMockit Coverage 旨在提供。
开发人员测试的另一部分
将会变得更加有用的工具集
随着测试套件规模的增长
逐步重新运行测试的能力
局部生产变更后
代码;这也包含在
覆盖率工具。

（当然，消息来源可能有偏见，但是……）

我会说使用JMockit。它是最容易使用、灵活的，并且适用于几乎所有情况，甚至是当您无法控制要测试的类（或者由于兼容性原因等而无法破坏它）时的困难情况和场景。

我使用 JMockit 的经历非常积极。

Update Sep 2019: The only mocking framework supported (by default) by Spring Boot is Mockito. If you use Spring, the answer is quite obvious.

I'd say the competition is between JMockit and PowerMock, then Mockito.

I'd leave "plain" jMock and EasyMock because they use only proxy & CGLIB and do not use Java 5 instrumentation like the newer frameworks.

jMock also didn't have a stable release for over 4 years. jMock 2.6.0 required 2 years to go from RC1 to RC2, and then another 2 years before it actually got released.

Regarding Proxy & CGLIB vs instrumentation:

(EasyMock and jMock) are based on java.lang.reflect.Proxy,
which requires an interface to be
implemented. Additionally, they
support the creation of mock objects
for classes through CGLIB subclass
generation. Because of that, said
classes cannot be final and only
overridable instance methods can be
mocked. Most importantly, however,
when using these tools the
dependencies of code under test (that
is, the objects of other classes on
which a given class under test
depends) must be controlled by the
tests, so that mock instances can be
passed to the clients of those
dependencies. Therefore, dependencies
can't simply be instantiated with the
new operator in a client class for
which we want to write unit tests.
Ultimately, the technical limitations
of conventional mocking tools impose
the following design restrictions on
production code:
Each class which may need to be mocked in a test must either implement
a separate interface or not be final.
The dependencies of each class to be tested must either be obtained
through configurable instance creation
methods (factories or a Service
Locator), or be exposed for dependency
injection. Otherwise, unit tests won't
be able to pass mock implementations
of dependencies to the unit under
test.
Since only instance methods can be mocked, classes to be unit tested
cannot call any static methods on
their dependencies, nor instantiate
them using any of the constructors.

The above is copied from http://jmockit.org/about.html . Further, it compares between itself (JMockit), PowerMock, and Mockito in several ways:

There are now other mocking tools for
Java which also overcome the
limitations of the conventional ones,
between them PowerMock, jEasyTest, and
MockInject. The one that comes closest
to the feature set of JMockit is
PowerMock, so I will briefly evaluate
it here (besides, the other two are
more limited and don't seem to be
actively developed anymore).
JMockit vs PowerMock
First of all, PowerMock does not provide a complete API for mocking,
but instead works as an extension to
another tool, which currently can be
EasyMock or Mockito. This is obviously
an advantage for existing users of
those tools.
JMockit, on the other hand, provides entirely new APIs, although
its main API (Expectations) is similar
to both EasyMock and jMock. While this
creates a longer learning curve, it
also allows JMockit to provide a
simpler, more consistent, and easier
to use API.
Compared to the JMockit Expectations API, the PowerMock API is
more "low-level", forcing users to
figure out and specify which classes
need to be prepared for testing (with
the @PrepareForTest({ClassA.class,
...}) annotation) and requiring
specific API calls to deal with
various kinds of language constructs
that may be present in the production
code: static methods
(mockStatic(ClassA.class)),
constructors
(suppress(constructor(ClassXyz.class))),
constructor invocations
(expectNew(AClass.class)), partial
mocks (createPartialMock(ClassX.class,
"methodToMock")), etc.
With JMockit Expectations, all kinds of methods and constructors are
mocked in a purely declarative way,
with partial mocking specified through
regular expressions in the @Mocked
annotation or by simply "un-mocking"
the members with no recorded
expectations; that is, the developer
simply declares some shared "mock
fields" for the test class, or some
"local mock fields" and/or "mock
parameters" for individual test
methods (and in this last case the
@Mocked annotation often won't be
needed).
Some capabilities available in JMockit, such as support for mocking
equals and hashCode, overridden
methods, and others, are currently not
supported in PowerMock. Also, there is
no equivalent to JMockit's ability to
capture instances and mock
implementations of specified base
types as the test executes, without
the test code itself having any
knowledge of the actual implementation
classes.
PowerMock uses custom class loaders (usually one per test class)
in order to generate modified versions
of the mocked classes. Such heavy use
of custom class loaders can lead to
conflicts with third-party libraries,
hence the need to sometimes use the
@PowerMockIgnore("package.to.be.ignored")
annotation on test classes.
The mechanism used by JMockit (runtime instrumentation through a
"Java agent") is simpler and safer,
although it does require passing a
"-javaagent" parameter to the JVM when
developing on JDK 1.5; on JDK 1.6+
(which can always be used for
development, even if deploying on an
older version) there is no such
requirement, since JMockit can
transparently load the Java agent on
demand by using the Attach API.
Another recent mocking tool is
Mockito. Although it does not attempt
to overcome the limitations of older
tools (jMock, EasyMock), it does
introduce a new style of behavior
testing with mocks. JMockit also
supports this alternative style,
through the Verifications API.
JMockit vs Mockito
Mockito relies on explicit calls to its API in order to separate code
between the record (when(...)) and
verify (verify(...)) phases. This
means that any invocation to a mock
object in test code will also require
a call to the mocking API.
Additionally, this will often lead to
repetitive when(...) and
verify(mock)... calls.
With JMockit, no similar calls exist. Sure, we have the new
NonStrictExpectations() and new
Verifications() constructor calls, but
they occur only once per test
(typically), and are completely
separate from the invocations to
mocked methods and constructors.
The Mockito API contains several inconsistencies in the syntax used for
invocations to mocked methods. In the
record phase, we have calls like
when(mock.mockedMethod(args))... while
in the verify phase this same call
will be written as
verify(mock).mockedMethod(args).
Notice that in the first case the
invocation to mockedMethod is made
directly on the mock object, while in
the second case it is made on the
object returned by verify(mock).
JMockit has no such inconsistencies because invocations to
mocked methods are always made
directly on the mocked instances
themselves. (With one exception only:
to match invocations on the same
mocked instance, an onInstance(mock)
call is used, resulting in code like
onInstance(mock).mockedMethod(args);
most tests won't need to use this,
though.)
Just like other mocking tools which rely on method
chaining/wrapping, Mockito also runs
into inconsistent syntax when stubbing
void methods. For example, you write
when(mockedList.get(1)).thenThrow(new
RuntimeException()); for a non-void
method, and doThrow(new
RuntimeException()).when(mockedList).clear();
for a void one. With JMockit, it's
always the same syntax:
mockedList.clear(); result = new
RuntimeException();.
Yet another inconsistency occurs in the use of Mockito spies: "mocks"
that allow the real methods to be
executed on the spied instance. For
example, if spy refers to an empty
List, then instead of writing
when(spy.get(0)).thenReturn("foo") you
will need to write
doReturn("foo").when(spy).get(0). With
JMockit, the dynamic mocking feature
provides similar functionality to
spies, but without this issue since
real methods only get executed during
the replay phase.
In EasyMock and jMock, the first mocking APIs for Java, the focus was
entirely on the recording of expected
invocations of mocked methods, for
mock objects that (by default) do not
allow unexpected invocations. Those
APIs also provide the recording of
allowed invocations for mock objects
that do allow unexpected invocations,
but this was treated as a second-class
feature. Additionally, with these
tools there is no way to explicitly
verify invocations to mocks after the
code under test is exercised. All such
verifications are performed implicitly
and automatically.
In Mockito (and also in Unitils Mock), the opposite viewpoint is
taken. All invocations to mock objects
that may happen during the test,
whether recorded or not, are allowed,
never expected. Verification is
performed explicitly after the code
under test is exercised, never
automatically.
Both approaches are too extreme, and consequently less than optimal.
JMockit Expectations & Verifications
is the only API that allows the
developer to seamlessly choose the
best combination of strict (expected
by default) and non-strict (allowed by
default) mock invocations for each
test.
To be more clear, the Mockito API has the following shortcoming. If you
need to verify that an invocation to a
non-void mocked method happened during
the test, but the test requires a
return value from that method that is
different from the default for the
return type, then the Mockito test
will have duplicate code: a
when(mock.someMethod()).thenReturn(xyz)
call in the record phase, and a
verify(mock).someMethod() in the
verify phase. With JMockit, a strict
expectation can always be recorded,
which won't have to be explicitly
verified. Alternatively, an invocation
count constraint (times = 1) can be
specified for any recorded non-strict
expectation (with Mockito such
constraints can only be specified in a
verify(mock, constraint) call).
Mockito has poor syntax for verifications in order, and for full
verifications (that is, checking that
all invocations to mock objects are
explicitly verified). In the first
case, an extra object needs to be
created, and calls to verify made on
it: InOrder inOrder = inOrder(mock1,
mock2, ...). In the second case, calls
like verifyNoMoreInteractions(mock) or
verifyZeroInteractions(mock1, mock2)
need to be made.
With JMockit, you simply write new VerificationsInOrder() or new
FullVerifications() instead of new
Verifications() (or new
FullVerificationsInOrder() to combine
both requirements). No need to specify
which mock objects are involved. No
extra mocking API calls. And as a
bonus, by calling
unverifiedInvocations() inside an
ordered verification block, you can
perform order-related verifications
that are simply impossible in Mockito.
Finally, the JMockit Testing Toolkit
has a wider scope and more ambitious
goals than other mocking toolkits, in
order to provide a complete and
sophisticated developer testing
solution. A good API for mocking, even
without artificial limitations, is not
enough for productive creation of
tests. An IDE-agnostic, easy to use,
and well integrated Code Coverage tool
is also essential, and that's what
JMockit Coverage aims to provide.
Another piece of the developer testing
toolset which will become more useful
as the test suite grows in size is the
ability to incrementally rerun tests
after a localized change to production
code; this is also included in the
Coverage tool.

(granted, the source may be biased, but well...)

I'd say go with JMockit. It's the easiest to use, flexible, and works for pretty much all cases even difficult ones and scenarios when you can't control the class to be tested (or you can't break it due to compatibility reasons etc.).

My experiences with JMockit have been very positive.

回复收藏 0 原文

说谎友 2024-10-07 17:54:01

我使用过 Mockito 和 JMockit，我对它们的体验是：

Mockito：
- 隐式模拟（-> 更好的可用性，但存在无法检测模拟上不允许的方法调用的危险）
- 显式验证
EasyMock：
- 明确的嘲笑
- 隐式验证
JMockit：
- 两者都支持
此外，JMockit 的其他优点：
- 如果您要模拟静态方法/构造函数等（例如在没有 UT 的情况下扩展非常旧的遗留代码库），您将有两种选择：1) 带有 Powermock 扩展的 Mockito/EasyMock 或 2) Jmockit
- 内置覆盖率报告

我个人更喜欢JMockit，我认为它的功能更丰富和灵活，但需要更陡峭的学习曲线。通常有多种方法可以实现相同的模拟效果，并且在设计模拟时需要更加小心。