kotlin调用类中的方法

by Oleksii Fedorov

通过Oleksii Fedorov

一种轻松的方法来测试Kotlin中令人沮丧的静态方法调用 (A stress-free way to test frustrating static method calls in Kotlin)

Let me make a wild guess… You have encountered some code in Kotlin that is using some third-party library. The API that the library provides is one or a few static methods. And you want to test some code using these static methods. It is painful.

让我大胆地猜测一下……您在Kotlin中遇到了一些使用某些第三方库的代码。该库提供的API是一种或几种静态方法。您想使用这些静态方法测试一些代码。真痛苦

You are not sure how to approach that problem.

您不确定如何解决该问题。

Perhaps you ask yourself, “When will third-party library authors stop using static methods?”

也许您问自己：“第三方库作者何时会停止使用静态方法？”

Anyway, who am I to tell you how to test static method calls in Kotlin?

无论如何，我该告诉谁如何在Kotlin中测试静态方法调用？

I’m a fanatic of testing and test-driven development evangelist for the last five years — they call me TDD Fellow for a reason. I have been working with Kotlin in production for about two years at the time of writing this.

在过去的五年中，我热衷于测试和测试驱动的开发宣传人员-他们之所以称呼我为TDD研究员，是有原因的。在撰写本文时，我已经在Kotlin的生产环境中工作了大约两年。

Onward!

向前！

That is how I feel when I see such awful APIs:

当我看到如此糟糕的API时，就是这种感觉：

Let me show you what I mean with a rough example that I have been dealing with recently. The library was a newrelic client. To use it I had to call a static method on some class. If simplified, it looks something like this:

让我通过最近处理的一个粗糙示例向您展示我的意思。该图书馆是newrelic客户。要使用它，我必须在某个类上调用静态方法。如果简化，它看起来像这样：

NewRelicClient.addAttributesToCurrentRequest(“orderId”, order.id)

I needed to change what exactly we are sending, and I had to add more attributes. Since I wanted to have confidence that my change is not breaking anything and does exactly the thing I want, I needed to write a test. There was no test for this code yet.

我需要更改发送的确切内容，并且必须添加更多属性。由于我想确信自己所做的更改不会破坏任何东西，并且完全可以完成我想要的事情，因此我需要编写测试。此代码尚未测试。

If you are still reading, I’m assuming you are in the same situation. Or you have been in the past.

如果您仍在阅读，我假设您处于相同的情况。或者您曾经去过。

I agree that is a painful situation.

我同意这是一个痛苦的情况。

How am I supposed to mock these calls in the test?

我应该如何在测试中模拟这些电话？

I know, it is frustrating that most of the mocking libraries are unable to mock static method calls. And even the ones that work in Java don’t always work in Kotlin.

我知道，令人沮丧的是，大多数模拟库无法模拟静态方法调用。甚至那些在Java中工作的工具也不一定总是在Kotlin中工作。

There are libraries that could do that, such as powermock, for instance. But you know what? Perhaps, you are already using mockito or some other library. Adding another mocking tool to the project will make things more confusing and frustrating.

有一些库可以做到这一点，例如powermock, 。但是你知道吗？也许，您已经在使用mockito或其他库。向项目添加另一个模拟工具会使事情变得更加混乱和令人沮丧。

I know how annoying it is to have multiple tools for the same job in the same codebase. That causes a hell lot of confusion for everyone.

我知道在同一代码库中为同一工作使用多个工具是多么烦人。这给每个人带来了很多混乱。

Well, that problem was already solved about two decades ago!

好吧，这个问题已经在大约二十年前解决了！

Interested? Come for a ride.

有兴趣吗过来兜风。

向谦虚对象重构 (Refactoring towards the Humble Object)

Let’s take a look at the code that we are working with here:

让我们看一下我们在这里使用的代码：

class FulfilOrderService {fun fulfil(order: Order) {// .. do various things ..NewRelicClient.addAttributesToCurrentRequest("orderId", order.id)NewRelicClient.addAttributesToCurrentRequest("orderAmount", order.amount.toString())}}

It is doing various things with the order to fulfill it, and then it is assigning a few attributes to the current request for newrelic.

它按照顺序执行各种操作，然后为当前请求newrelic分配一些属性。

The first thing that we will do together here is extract the method addAttributesToRequest. We also want to parametrize it with key and value arguments. You can do so manually, or, if you are lucky enough to use IntelliJ IDEA, you can do such refactoring automatically.

我们将在这里一起做的第一件事是提取方法addAttributesToRequest 。我们还希望使用key和value参数对其进行参数化。您可以手动执行此操作，或者，如果有幸使用IntelliJ IDEA，则可以自动执行此类重构。

Here is how:

方法如下：

Select ”orderId” and extract a local variable. Name it key.
选择”orderId”并提取局部变量。将其命名为key 。
Select order.id and extract a local variable. Name it value.
选择order.id并提取局部变量。将其命名为value 。
Select NewRelicClient.addAttributesToCurrentRequest(key, value) and extract a method. Name it addAttributesToRequest.
选择NewRelicClient.addAttributesToCurrentRequest(key, value)并提取一个方法。将其命名为addAttributesToRequest 。
IntelliJ will highlight that second call to NewRelicClient as a duplicate and tell you that you can replace it with the call to the new private method. IntelliJ will ask you if you want to do that. Do it.
IntelliJ将重复显示对NewRelicClient第二次调用，并告诉您可以将其替换为对新的private方法的调用。 IntelliJ会询问您是否要这样做。做吧
Inline variables key and value.
内联变量key和value 。
Finally, make the method protected instead of private. I’ll show you in a bit why the method has to be protected.
最后，将方法设置为protected而不是private 。我将向您介绍为什么必须保护该方法。
You’ll notice that IntelliJ highlights protected with a warning. That is because all classes in Kotlin are final by default. As final classes are not extendable, protected is useless. One of the solutions IntelliJ offers is to make the class open. Do it. The method addAttributesToRequest should become open too.
您会注意到IntelliJ高亮显示protected警告protected 。这是因为默认情况下，Kotlin中的所有类都是final 。由于最终类不能扩展，因此protected是没有用的。 IntelliJ提供的解决方案之一是使类open 。做吧方法addAttributesToRequest应该打开。

Here is what you should get in the end:

这是您最终应该得到的：

open class FulfilOrderService {fun fulfil(order: Order) {// .. do various things ..addAttributesToRequest("orderId", order.id)addAttributesToRequest("orderAmount",order.amount.toString())}protected open fun addAttributesToRequest(key: String,value: String) {NewRelicClient.addAttributesToCurrentRequest(key, value)}}

Notice, how all these refactorings were completely automatic and therefore safe to execute. We do not need tests to do these. Having that method as protected will give us the opportunity to write a test:

注意，所有这些重构都是完全自动化的，因此可以安全执行。我们不需要测试即可执行这些操作。使该方法受到保护将使我们有机会编写测试：

private val attributesAdded = mutableListOf<Pair<String, String>>()private val subject = FulfilOrderService()@Test
fun `adds order id to the current request within newrelic`() {val order = Order(id = "some-id", amount = 142)subject.fulfil(order)val expectedAttributes = listOf(Pair("orderId", "some-id"),Pair("orderAmount", "142"))assertEquals(expectedAttributes, attributesAdded)}

Speaking of tests and refactoring…

谈到测试和重构……

Do you want to learn how to write an acceptance test in Kotlin? Maybe, how to use the power of IntelliJ IDEA to your advantage?

您是否想学习如何在Kotlin中编写验收测试？也许，如何利用IntelliJ IDEA的功能来发挥自己的优势？

Perhaps, you want to learn how to build applications in Kotlin well? — be it command-line, web or android apps?

也许，您想学习如何在Kotlin中很好地构建应用程序？ —是命令行，Web还是Android应用程序？

There is this ultimate tutorial e-book that I have ACCIDENTALLY written about getting started with Kotlin. 350 pages of hands-on tutorial that you can follow along.

我偶然地写了这本终极教程电子书，介绍了Kotlin入门。您可以遵循350页的动手教程。

You will feel as if I’m sitting together with you and we are enjoying our time, all the while building a full-fledged command-line application.

在构建一个完整的命令行应用程序的同时，您会感觉好像我和您坐在一起，我们正在享受我们的时光。

Interested?

有兴趣吗

Download the ultimate tutorial here. By the way, it is free and will always be!

在此处下载最终教程。顺便说一句，它是免费的，而且永远都是！

Going back to our test.

回到我们的测试。

That all looks correct, but it doesn’t work because nobody is adding any elements to the list attributesAdded. Since we have that small protected method, we can “hack into it”:

一切看上去都是正确的，但是它没有用，因为没有人向列表attributesAdded Artprice添加任何元素。由于我们拥有受保护的小方法，因此我们可以“破解”它：

private val subject: FulfilOrderService = object :FulfilOrderService() {override fun addAttributesToRequest(key: String,value: String) {attributesAdded.add(Pair(key, value))}}

If you run the test, it passes. You can change values in the test or production code to see the failure and make sure that it indeed is testing what you think it does.

如果运行测试，则测试通过。您可以在测试或生产代码中更改值以查看故障，并确保它确实在测试您认为是什么。

Let’s see the whole test code:

让我们看一下整个测试代码：

import org.junit.Assert.*
import org.junit.Test@Suppress("FunctionName")
class FulfilOrderServiceTest {private val attributesAdded = mutableListOf<Pair<String, String>>()private val subject: FulfilOrderService = object :FulfilOrderService() {override fun addAttributesToRequest(key: String,value: String) {attributesAdded.add(Pair(key, value))}}@Testfun `adds order id to the current request within newrelic`() {val order = Order(id = "some-id", amount = 142)subject.fulfil(order)val expectedAttributes = listOf(Pair("orderId", "some-id"),Pair("orderAmount", "142"))assertEquals(expectedAttributes, attributesAdded)}}

So, what just happened here?

那么，这里发生了什么？

See, I’ve made a slightly different version of FulfilOrderService class — a testable one. The only weakness of this testing method is that if somebody screws up with addAttributesToRequest function, no test will break.

瞧，我制作了一个稍有不同的FulfilOrderService类版本-一个可测试的类。这种测试方法的唯一缺点是，如果有人用addAttributesToRequest函数addAttributesToRequest ，那么测试就不会addAttributesToRequest 。

On the other hand, that function will never have to contain more than one line of simple code and will probably not change that often. That will happen only in the case when authors of the third-party library that we are using are going to introduce a breaking change to that single method.

另一方面，该函数将不必包含多于一行的简单代码，并且可能不会经常更改。只有当我们正在使用的第三方库的作者打算对该单一方法进行重大更改时，这种情况才会发生。

That is unlikely. Will happen probably every few years.

那是不可能的。大概每隔几年就会发生一次。

And you know what?

你知道吗？

Even if you do test it somehow more “black-box’ey” than what I’m offering here, when such breaking change comes around the block, you’ll still have to re-visit all the usages and fix them. Probably, you will need to throw away or rewrite all the related tests too.

即使您以某种方式比我在此处提供的测试来测试“ black-box'ey”，当这种突破性变化即将到来时，您仍然必须重新查看所有用法并进行修复。可能您也需要丢弃或重写所有相关测试。

Oh, and in case of such breaking change, I would still recommend testing manually at least once to see if you understood the new API correctly and it interacts with the third-party system in a way you think it should.

哦，如果发生这种重大更改，我仍然建议至少手动测试一次，以了解您是否正确理解了新API，并且该API与第三方系统以您认为应该的方式进行交互。

Given all this information, I guess it should be alright to leave that one line untested.

有了所有这些信息，我想应该保留那一行未经测试。

But if such change comes around the block, do you have to hunt for all the places where we are calling to NewRelicClient?

但是，如果这种变化即将到来，您是否必须寻找我们打电话给NewRelicClient所有地方？

Short answer — yes.

简短的答案-是的。

Long answer: in current design — yes. But did you think we are done here?

长答案：在当前设计中-是的。但是您认为我们已经完成了吗？

Nope.

不。

The design is terrible as it is right now. Let’s fix that via extraction of the Humble Object. Once we do that, there will be only one place in a whole code base that will require change — that humble object.

现在的设计很糟糕。让我们通过提取Humble Object来解决此问题。一旦做到这一点，整个代码库中只有一个地方需要更改—一个不起眼的对象。

Unfortunately, IntelliJ doesn’t support Move method or Extract method object refactorings for Kotlin quite yet, so we will have to perform this one manually.

不幸的是，IntelliJ还不支持Kotlin的Move method或Extract method object重构，因此我们将不得不手动执行此操作。

But you know what? — It is OK because we already have related tests backing us up!

但是你知道吗？ —可以，因为我们已经有相关的测试支持我们！

To do the Extract method object refactoring, we will need to replace the implementation inside of the method with object creation, and immediate call to the method of that object with the same arguments as the refactored method has:

要进行Extract method object重构，我们需要用对象创建来替换方法内部的实现，并使用与重构方法具有相同参数的立即调用该对象的方法：

protected open fun addAttributesToRequest(key: String,value: String) {//   NewRelicClient.addAttributesToCurrentRequest(key, value)NewRelicHumbleObject().addAttributesToRequest(key, value)}

Then we will need to create this class and create the method on it. Finally, we will put the contents of the refactored method, the one we have commented out, to the freshly created method; don’t forget to remove the comment as we don’t need it anymore:

然后，我们将需要创建此类并在其上创建方法。最后，我们将重构方法的内容(我们已注释掉的内容)放到新创建的方法中。不要忘记删除评论，因为我们不再需要它了：

class NewRelicHumbleObject {fun addAttributesToRequest(key: String, value: String) {NewRelicClient.addAttributesToCurrentRequest(key, value)}}

We are done with this step of refactoring, and we should run our tests now. They all should pass if we didn’t make any mistakes — and they do!

我们已经完成了重构的这一步，现在应该运行测试。如果我们没有犯任何错误，他们都应该通过-他们做到了！

The next step in this refactoring is to move creation of the humble object into the field. Here we can perform an automated refactoring to extract the field from the expression NewRelicHumbleObject(). That is what you should get after the refactoring:

重构的下一步是将不起眼的对象的创建移到现场。在这里，我们可以执行自动重构以从表达式NewRelicHumbleObject()提取字段。这是重构后应该得到的：

private val newRelicHumbleObject = NewRelicHumbleObject()protected open fun addAttributesToRequest(key: String,value: String) {newRelicHumbleObject.addAttributesToRequest(key, value)}

Now, because we have that value in the field, we can move it to the constructor. There is an automated refactoring for that too! It is called Move to constructor. You should get the following result:

现在，由于我们在字段中具有该值，因此可以将其移至构造函数。也有自动重构功能！这称为“ Move to constructor 。您应该得到以下结果：

open class FulfilOrderService(private val newRelicHumbleObject: NewRelicHumbleObject =NewRelicHumbleObject()) {fun fulfil(order: Order) {// .. do various things ..addAttributesToRequest("orderId", order.id)addAttributesToRequest("orderAmount",order.amount.toString())}protected open fun addAttributesToRequest(key: String,value: String) {newRelicHumbleObject.addAttributesToRequest(key, value)}}

That will make it super simple to inject the dependency from the test. And notice, it is an ordinary object with one non-static method.

这将使注入测试中的依赖关系变得非常简单。请注意，它是使用一种非静态方法的普通对象。

Do you know what that means?

你知道那是什么意思吗？

Yes! You can use your favorite mocking tool to mock that. Let’s do just that now. I’ll use mockito for this example.

是! 您可以使用自己喜欢的模拟工具进行模拟。现在就开始做吧。在此示例中，我将使用mockito 。

First, we will need to create the mock in our test:

首先，我们需要在测试中创建模拟：

private val newRelicHumbleObject =Mockito.mock(NewRelicHumbleObject::class.java)

To be able to mock our humble object, we will have to make its class open and the method addAttributesToRequest open too:

为了能够模拟我们的谦逊对象，我们必须使其类open并且方法addAttributesToRequest打开：

open class NewRelicHumbleObject {open fun addAttributesToRequest(key: String, value: String) {// ...}}

Then we will need to provide that mock as an argument to FulfilOrderService’s constructor:

然后，我们需要将该模拟作为FulfilOrderService构造函数的参数提供：

private val subject = FulfilOrderService(newRelicHumbleObject)

Finally, we want to replace our assertion with mockito’s verification:

最后，我们要用mockito的验证替换断言：

Mockito.verify(newRelicHumbleObject).addAttributesToRequest("orderId", "some-id")
Mockito.verify(newRelicHumbleObject).addAttributesToRequest("orderAmount", "142")
Mockito.verifyNoMoreInteractions(newRelicHumbleObject)

Here we are verifying that our humble object’s method addAttributesToRequest has been called with appropriate arguments twice and with nothing else. And we don’t need attributesAdded field anymore, so let’s get rid of that.

在这里，我们验证了谦虚对象的方法addAttributesToRequest是否已使用适当的参数调用了两次，并且没有其他任何调用。并且我们不再需要attributesAdded字段，因此让我们摆脱它。

Here is what you should get now:

这是您现在应该得到的：

class FulfilOrderServiceTest {private val newRelicHumbleObject =Mockito.mock(NewRelicHumbleObject::class.java)private val subject = FulfilOrderService(newRelicHumbleObject)@Testfun `adds order id to the current request within newrelic`() {val order = Order(id = "some-id", amount = 142)subject.fulfil(order)Mockito.verify(newRelicHumbleObject).addAttributesToRequest("orderId", "some-id")Mockito.verify(newRelicHumbleObject).addAttributesToRequest("orderAmount", "142")Mockito.verifyNoMoreInteractions(newRelicHumbleObject)}}

Now that we are not overriding that protected method anymore, we can inline it. By the way, the class doesn’t have to be open anymore. Our FulfilOrderService class is now ready to accept the changes that we wanted to make, as it is testable now (at least in regard to newrelic request attributes):

现在我们不再覆盖该受保护的方法，可以对其进行内联。顺便说一句，该类不必再open了。现在，我们的FulfilOrderService类已经准备好接受我们想要进行的更改，因为它现在可以测试(至少对于newrelic请求属性而言)：

class FulfilOrderService(private val newRelicHumbleObject: NewRelicHumbleObject = NewRelicHumbleObject()) {fun fulfil(order: Order) {// .. do various things ..newRelicHumbleObject.addAttributesToRequest("orderId", order.id)newRelicHumbleObject.addAttributesToRequest("orderAmount", order.amount.toString())}}

Let’s run all the tests again, just for good measure! — they all pass.

让我们再次运行所有测试，以防万一！ -他们都通过了。

Great, I think we are done here.

太好了，我想我们已经完成了。

Thank you for reading!

感谢您的阅读！

It would make me happy if you shared what you think of such refactoring in the comments. Do you know a simpler way to refactor that? — share!

如果您在评论中分享您对这种重构的想法，那会让我感到高兴。您知道一种更简单的重构方法吗？ -分享！

Also, if you like what you see, consider giving me a clap on Medium and sharing the article on social media.

另外，如果您喜欢自己所看到的内容，请考虑给我一个鼓掌，并在社交媒体上分享该文章。

If you are interested in learning Kotlin and you like my writing style, grab my ultimate tutorial on getting started with Kotlin.

如果您对学习Kotlin感兴趣并且喜欢我的写作风格，请阅读有关Kotlin入门的最终教程。

How Kotlin’s “@Deprecated” Relieves Pain of Colossal Refactoring?I’m going to tell you a real story how we saved ourselves tons of time. The power of Kotlin’s @Deprecated refactoring…hackernoon.com

Kotlin的“ @Deprecated”如何减轻巨大重构的痛苦？ 我将告诉您一个真实的故事，我们如何节省自己的大量时间。 Kotlin @Deprecated重构的力量…… hackernoon.com

How Kotlin Calamity Devours Your Java Apps Like Lightning?I hear what you are saying. There is that buzz around Android actively adopting Kotlin as a primary programming…hackernoon.com

Kotlin灾难如何像闪电一样吞噬您的Java应用程序？ 我听到你在说什么。 围绕Android积极采用Kotlin作为主要编程的嗡嗡声…… hackernoon.com

Parallel Change RefactoringParallel Change is the refactoring technique that allows implementing backward-incompatible changes to an API in a safe…medium.com

平行变化重构 平行的变化是，允许在安全落实的API后向兼容的变化重构技术... medium.com