我们有几个非常非常慢的 JUnit 测试，它们大量使用模拟，包括静态函数的模拟。单个测试需要 20-30 秒，整个“mvn 测试”需要 25 分钟。
我想分析时间浪费在哪里，但在分析方面缺乏经验。
我认为依赖模拟对象的初始化花费了太长的时间。
两个问题：
1）如何快速获取数字，哪些方法浪费了时间？我不需要复杂的高级用户工具，只需要一些基本的工具来获取数字。 （有证据表明我们所做的那种嘲笑是邪恶的）
2）你知道什么设计缺陷会产生如此糟糕的时机吗？我们测试应该调用模拟服务的 JSF 支持 bean。也许支持 bean 中可能存在一些输入验证或未重构的业务逻辑，但无法更改（请不要对此发表评论;-) ）
ad 2）例如，一个测试有大约 30 个（！）类需要处理准备使用@PrepareForTest 进行测试。这不太好，但我无法解释为什么。
We have a couple of very very slow JUnit tests that make heavy use of mocking, including Mocking of static functions. Single Tests take 20-30 secs, the whole "mvn test" takes 25 minutes.
I want to analyze where the time is wasted but have little experience in profiling.
I assume that the initialization of the dependent mock-objects takes much too long.
Two questions:
1) How can I quickly get numbers in which methods the time is wasted? I need no complex power-user tool, just something basic to get the numbers. (evidence that the kind of mocking we do is evil)
2) Do you have ideas what design-flaws can produce such bad timings? We test JSF-backing beans that should call mocked services. Perhaps there might be some input-validation or not-refactored business logic in the backing beans, but that cannot be changed (pls dont comment on that ;-) )
ad 2) For example one test has about 30 (!) classes to be prepared for test with @PrepareForTest. This cannot be good, but I cannot explain why.
发布评论
评论（1）
这是我对此的输入：
尝试使用简单的东西，例如 Apache Commons StopWatch 类。我发现这是发现代码中瓶颈的简单方法，通常当您找到第一个瓶颈时，其余的瓶颈就更容易发现。我几乎从不浪费时间尝试配置过于复杂的分析工具。
我认为在完全模拟的单元测试中出现这样的性能缺陷很奇怪。如果我猜的话，我会说您缺少一两个模拟组件，并且数据库或外部 Web 服务实际上在您不知情的情况下被调用。当然，我可能是错的，因为我不使用 PowerMock，并且我强调永远不要模拟任何静态方法。这是您目前最大的设计缺陷，也是对代码提供良好测试覆盖率的最大障碍。那么该怎么办呢？您有两个选择，您可以将静态方法重构为更容易模拟的类方法。另一种选择是将静态方法包装在类对象包装器中，然后模拟该包装器。如果静态方法来自我没有源代码的第三方库，我通常会这样做。
一个测试有大约 30 (!) 个类需要准备使用 @PrepareForTest 进行测试。这不太好，但我无法解释原因。这听起来确实像您可能还有一些做得太多的方法！对于单个方法来说，大约有太多的依赖项99%的情况。该方法很可能可以分为单独的更容易测试的方法。希望这有帮助。
Here is my input on this:
Try using something simple like the Apache Commons StopWatch class. I find that this is an easy way to spot bottle necks in code, and usually when you find what the first bottlneck is then the rest of them are easier to spot. I almost never waste my time trying to configure an overly complicated profiling tool.
I think it is odd that you have such performance flaws in fully mocked unit tests. If I were to guess I would say that you are missing one or two mocked components and the database or external web services are actually being called without you knowing about it. Of course I may be wrong, because I don't use PowerMock and I make it a point to never mock any static methods. That is your biggest design flaw right now and the biggest hindrance to providing good test coverage on your code. So what to do? You have 2 options, you can refactor the static methods into class methods that can be more easily mocked. The other option is that you wrap the static methods in a class object wrapper, and then mock the wrapper instead. I typically do this if the static methods are from a third-party library where I do not have the source.
one test has about 30 (!) classes to be prepared for test with @PrepareForTest. This cannot be good, but I cannot explain why.This really sounds like you may also have methods that are doing entirely too much! That is just too many dependencies for a single method in about 99% of cases. More than likely this method can be seperated into seperate more easily testable methods.Hope this helps.