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