PowerMock + Mockito VS Mockito一个人 [英] PowerMock + Mockito VS Mockito alone

问题描述

任何人都可以总结一下，具体功能是什么让你在Mockito上添加PowerMock？

Can anyone please summarize, what exactly features gives you adding PowerMock on top of the Mockito?

到目前为止，我发现了这些：

So far I've found these:

• 模拟静态，最终和私有方法


• 删除静态初始化程序


• 允许模拟没有依赖注入 - 这个我不清楚。你能详细说明吗？

它是否会添加其他内容？你能用几行总结一下吗？

Does it add anything else? Can you please sum up in several lines?

在使用PowerMock时我是否需要牺牲一些东西？

And do I need to sacrifice something when using PowerMock?

推荐答案

我不知道其他好处，但我想解决你的两个子问题（这对评论来说太长了）：

I don't know of other benefits offhand, but I want to address 2 of your sub-questions (and this is way too long for a comment):

允许在没有依赖注入的情况下进行模拟 - 这个对我来说并不清楚。你能详细说明一下吗？

allow mocking without dependency injection - this one isn't clear to me. Can you elaborate?

我认为这来自 Motivation wiki页面，它们描述了一种重构代码的方法，即不调用静态方法使其可测试。对于我认为他们正在进行的具体示例，假设你有这个代码，并且你想测试模拟静态方法行为的方法，而不使用powermock：

I think this came from the Motivation wiki page where they describe a way of refactoring code to not invoke static methods to make it testable. For a concrete example of what I think they're getting at, let's say you have this code and you want to test the method mocking the behaviour of the static method, without using powermock:

public class MyClass {
     public void doGetString() {
         ...
         OtherClass.getString(); //It's complex and scary and needs mocking!
         ...
     }
}

一个解决方案，会将静态调用拉入自己的对象，然后注入一个可以模拟到测试时间的对象。例如，不使用其他框架，这可能如下所示：

One solution, would be to pull the static invocation into its own object, then inject an object that can be mocked come test time. For example, without using other frameworks, this could look like:

public class MyClass {
     public static class StringGetter {
         public getString() {
             return OtherClass.getString();                 
         }
     }

     private final StringGetter getter;

     //Existing Constructor
     public MyClass() {
         this(new StringGetter());
     }

     //DI Constructor
     MyClass(StringGetter getter) {
         this.getter = getter;
     }

     public void doGetString() {
         ...
         getter.getString();
         ...
     }
}

我已分开我的方法的行为来自静态调用的行为，并且可以使用DI构造函数在测试时轻松注入模拟。当然有了powermock我可以只是模拟静态方法，然后运行它。

I've seperated the behaviour of my method from the behaviour of the static invocation, and can use the DI constructor to inject mocks easily at test time. Of course with powermock I could just mock the static method in place, and run with it.

我在使用时需要牺牲一些东西吗？ PowerMock？

And do I need to sacrifice something when using PowerMock?

实际上没有，但我会说哲学上是的:)。以下是我的意见，我试图给出他们背后的充分理由，但当然他们是意见所以请他们带着一点点盐：

Physically no, but I'd say philosophically yes :). The below are my opinions, and I try to give good reasons behind them, but of course they are opinions so take them with a grain of salt:

潜在可怕的事情PowerMock正在发生的事情是，为了完成模拟私有和静态方法的功能，他们使用自定义类加载器（生产中不应该出现在运行时）并更改类的字节码。可以说，绝大多数类在大多数情况下这都不重要，但是如果你考虑一下，如果字节码发生了变化，并且某些副作用不再存在，你就可以根据你的不同来有效地测试不同的类了。现有的类。是的，这是一个非常学术性的论点。

The potentially scary thing that is happening with PowerMock is that in order to accomplish the feats of mocking private and static methods, they are using a custom class loader (which shouldn't be present at runtime in production) and changing the bytecode of your classes. Arguably, this should not matter with the vast majority of classes most of the time, but if you think about it, if the bytecode has changed, and certain side effects are no longer present, you're effectively testing different Classes albiet based upon your existing Classes. Yes this is a very academic argument.

通过良好的全面集成和不使用PowerMock的更高级别测试，您可以在某种程度上缓解第一个参数。通过这种方式，即使您的单元测试使用PowerMock，您也可以对对象的行为更有信心。

You can somewhat mitigate this first argument by having good comprehensive integration and higher level tests that don't use PowerMock. In this way you can be more confident in the behaviours of your objects even if your unit tests are using PowerMock.

我对PowerMock的另一个论点是，它可以几乎太容易成为拐杖。我同意PowerMock可以帮助测试使用遗留代码的代码以及您无法控制的其他代码。但是我会争辩说，当你控制你需要模拟的类时，你应该避免使用它。如果你使用私有方法或静态方法编写一个类，你需要显式模拟以测试其他方法，我的直觉就是说这个方法可能做得太多，应该重构和分解。让PowerMock在一个项目中已经可用，你可能只想嘲笑它并继续前进，这将减轻应该鼓励你重构的痛苦。是的，有时由于各种技术和非技术限制这是不可能的，但是解决痛点而不是避免它们是好的：）

The other argument I have against PowerMock, is that it could almost too easily become a crutch. I agree that PowerMock can help with testing code that uses legacy code and other code that you do not have control over. However I would argue that when you have control over the classes that you need to mock, you should avoid its use. If you write a class with a private method or static method that you need to explicitly mock in order to test other methods, my gut instinct would say that this method may be doing too much and should be refactored and broken up. Having PowerMock already available in a project, you may be tempted to just mock it and move on, which would mitigate the pain that should encourage you to refactor the same. Yes there are sometimes due to various technical and non-technical constraints this is not possible, but it's good to solve pain points instead of avoid them :)

这篇关于PowerMock + Mockito VS Mockito一个人的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！