小編給大家分享一下怎么測試RxJava代碼，希望大家閱讀完這篇文章之后都有所收獲，下面讓我們一起去探討吧！
成都創(chuàng)新互聯(lián)專注于琿春企業(yè)網(wǎng)站建設(shè),成都響應(yīng)式網(wǎng)站建設(shè),商城網(wǎng)站建設(shè)?，q春網(wǎng)站建設(shè)公司,為琿春等地區(qū)提供建站服務(wù)。全流程定制網(wǎng)站制作，專業(yè)設(shè)計，全程項目跟蹤，成都創(chuàng)新互聯(lián)專業(yè)和態(tài)度為您提供的服務(wù)
使用響應(yīng)式編程，就必須轉(zhuǎn)變對給定問題的推理方式，因為我們要聚焦于作為事件流的流動數(shù)據(jù)，而非個別數(shù)據(jù)項。事件通常是被不同的線程所產(chǎn)生和消費，因此在編寫測試時必須要對并發(fā)問題有著清晰的認(rèn)識。幸運的是，RxJava提供了測試Observable和Subscription的內(nèi)建支持，并且是直接構(gòu)建于RxJava的核心依賴中。
第一步
讓我們回顧一下在“RxJava入門之實例解析”一文中所給出的那個詞匯的例子，看一下如何對該例子作測試。讓我們從基礎(chǔ)測試工具的設(shè)置開始。在我們的測試架構(gòu)中，使用了JUnit作為測試工具。
事實上在沒有給定調(diào)度器(Scheduler)的情況下，Subscription將默認(rèn)運行于調(diào)用線程上。因此我們將在***測試中使用原生的方法。這意味著我們可實現(xiàn)一個Subscription接口的對象，在Subscription發(fā)生后就立刻對其狀態(tài)做斷言(assert)。
注意這里使用了顯式的List
TestSubscriber不僅可替代用戶累加器，還另給出了一些行為。例如它能夠給出接收到的消息和每個事件相關(guān)數(shù)據(jù)的規(guī)模，它也可對Subscription被完成且在Observable消費期間沒有錯誤出現(xiàn)的狀態(tài)做斷言。雖然當(dāng)前測試中的Observable并未生成任何的錯誤，但是回到“RxJava入門之實例解析”一文，我們從中得知了Observable將例外與數(shù)據(jù)事件等同對待。我們可通過如下的方式通過連接例外事件而模擬錯誤：
在我們所給出的有限用例中，所有的機制運行良好。但是實際的產(chǎn)品代碼可能會完全不同于例子。因此在下文中，我們將考慮一些更加復(fù)雜的產(chǎn)品實例。
定制調(diào)度器(Scheduler)
在產(chǎn)品代碼中，很多用例中的Observable都是在特定的線程上執(zhí)行，這種線程在響應(yīng)式編程環(huán)境中被稱為“調(diào)度器(Scheduler)”。很多Observable操作將可選的調(diào)度器參數(shù)作為附加參數(shù)使用。RxJava定義了一系列任何時候都可用的命名調(diào)度器，包括IO調(diào)度器(io)、計算調(diào)度器(computation，為共享線程)和新線程調(diào)度器(newThread)。開發(fā)人員也可去實現(xiàn)個人定制的調(diào)度器。讓我們通過指定計算調(diào)度器來修改Observable的代碼吧。
當(dāng)運行時就會立刻發(fā)現(xiàn)該代碼是存在問題的。Subscriber在測試線程上執(zhí)行其斷言，但是Observable在后臺線程(計算線程)上生成值。這意味著執(zhí)行Subscriber斷言可能先于Observable生成所有相關(guān)事件，因而導(dǎo)致測試的失敗。
為使測試順利執(zhí)行，有如下的一些策略可選：
將Observable轉(zhuǎn)化為阻塞式的。
強制測試等待，直至給定的條件被滿足。
將計算調(diào)度器轉(zhuǎn)換為即刻(Schedulers.immediate())調(diào)度器。
我們將對每個策略做展開介紹，但將從“將Observable轉(zhuǎn)化為阻塞式”開始，因為實現(xiàn)該策略所需做的技術(shù)工作最少，這些工作與所使用的調(diào)度器無關(guān)。我們假設(shè)數(shù)據(jù)在后臺線程中生成，這將導(dǎo)致Subscriber從同一后臺線程得到通知。
我們要做的是強制生成所有的事件，并在下一個聲明被執(zhí)行前就在測試中完成Observable。這是通過在Observable自身上調(diào)用toBlocking()方法實現(xiàn)的。
該方法雖然適用于我們所給出的簡單代碼，但可能并不適用于實際的產(chǎn)品代碼。如果生產(chǎn)者生成所有的數(shù)據(jù)需要很長的時間，那將會產(chǎn)生什么后果?這將使測試變得非常慢，并增加了編譯時間，還可能會有其它的性能問題。這里我推薦一個便利的程序庫，就是Awaitility(https://github.com/awaitility/awaitility)。簡單地說，Awaitility是一個以精確、簡單易讀的方式對異步系統(tǒng)相關(guān)期望進行表述的DSL。在項目中可以用Maven添加Awaitility的依賴關(guān)系。
org.awaitility awaitility 2.0.0 test
或是使用Gradle：
testCompile 'org.awaitility:awaitility:2.0.0'
Awaitility DSL的接入點是org.awaitility.Awaitility.await()方法(參見下面例子中的第13和14行代碼)?？梢允褂肁waitility定義使測試?yán)^續(xù)所必須達成的條件，也可在條件中加入超時或其它的時序約束，例如最小、***或持續(xù)范圍。對于上面的例子，下面的代碼給出了如何在結(jié)果中使用Awaitility：
此版本測試并未以任何方式改變Observable的本質(zhì)，這使得你做測試時不必對產(chǎn)品代碼做任何改動。該版本測試使用最多2秒的等待時間通過檢查Subscriber狀態(tài)使Observable執(zhí)行其作業(yè)。如果一切進行順利，在2秒內(nèi)就可將Subscriber的狀態(tài)釋放給所有的9個事件。
Awaitility具有和Hamcrest的匹配符、Java 8的lambda表達式和方法引用等的良好協(xié)作，從而給出精確的和可讀的測試條件。Awaitility還提供了預(yù)制擴展，用于那些被廣泛使用的JVM語言，其中包括Groovy和Scala。
我們要給出***一個策略中使用了RxJava的擴展機制，該擴展是以RxJava API的組成部分發(fā)布的。RxJava中定義了一系列的擴展點，允許對幾乎任何默認(rèn)的RxJava行為進行微調(diào)。這種擴展機制使我們可以針對特定的RxJava特性提供修改過的值。利用該機制，在無需關(guān)心生成代碼中所指定的調(diào)度器的情況下，我們可在測試中注入選定的調(diào)度器。這正是我們所尋找的方法，該方法被封裝在RxJavaHooks類中。假設(shè)產(chǎn)品代碼依賴于計算調(diào)度器，我們將覆蓋它的默認(rèn)值，返回一個調(diào)度器，它作為被調(diào)用的代碼使事件處理發(fā)生，這是即刻調(diào)度器(Schedulers.immediate())。下面給出測試的代碼：
在測試中，產(chǎn)品代碼察覺不到計算調(diào)度器是即刻的。請注意鉤子函數(shù)必須被重置，否則即刻調(diào)度器的設(shè)置可能會發(fā)生泄漏，導(dǎo)致在各處的測試被破壞。使用try/finall代碼塊會在一定程度上模糊了測試的目的，但是幸運的是我們可以使用JUnit規(guī)則重構(gòu)該行為，使測試更加精煉，結(jié)果更可讀。下面給出使用上述規(guī)則的一種可能的實現(xiàn)代碼：
此外，我們還對另外兩個調(diào)度器的生成方法做了重寫。該規(guī)則對此后其它的測試目標(biāo)更為通用。在新的測試用例類中，該規(guī)則的使用方法很直接，只需簡單地定義一個域，并將其中新類型標(biāo)注為@Rule即可。示例代碼如下：
最終我們可得到與前面測試一樣的行為，卻沒有像前面測試那樣的雜亂。下面用一些篇幅來回顧一下我們目前已經(jīng)做到的事情：
Subscribers將在同一線程中處理數(shù)據(jù)，只要沒有使用特定的調(diào)度器。這意味著在Subscriber向Observable做訂閱后，我們就可在該Subscriber上做斷言。
TestSubscriber可累計事件，并給出自身狀態(tài)的追加斷言。
任何Observable都可轉(zhuǎn)換為阻塞式的，這使得無論Observable使用何種調(diào)度器，我們都可以同步等待事件的生成。
RxJava提供了擴展機制，允許開發(fā)人員重寫其默認(rèn)方法，并以適當(dāng)?shù)姆绞阶⑷氲疆a(chǎn)品代碼中。
并發(fā)代碼可使用Awaitility DSL測試。
上述的每個技術(shù)都作用于不同的場景中，但是所有技術(shù)都是通過“共同的線程”(譯者注：作者在原文中指出common thread是作為雙關(guān)語使用的，其另一個意思是“類似的思路”)相關(guān)聯(lián)：在對Subscriber狀態(tài)做斷言之前，測試代碼需等待Observable完成?？紤]到Observable的行為會生成數(shù)據(jù)，是否有方法對該行為進行檢查呢?換句話說，是否可以用編程的方式做Observable的現(xiàn)場調(diào)試?我們將在后文中給出這樣的技術(shù)。
操控時間
到目前為止我們已用黑箱方式測試了Observable和Subscription。下面我們將考慮另外一種操控時間的技術(shù)，該技術(shù)使我們可以在Observable依然處于活動狀態(tài)時，打開引擎蓋去查看Subscriber狀態(tài)。換句話說，我們將使用采用了RxJava的TestScheduler類白箱測試技術(shù)，這可以說是RxJava再一次來救場。這種特定的調(diào)度器可精確地設(shè)定時間的內(nèi)部使用方式，例如可將時間提前半秒，或是使時間跳躍5秒。我們將首先給出這種新調(diào)度器實例的創(chuàng)建方法，然后再討論代碼的測試。
該“產(chǎn)品”代碼有了略微的改變，這是由于我們使用了綁定到調(diào)度器時隙(interval())的方法生成計數(shù)(第6行)，而非生成一個計數(shù)的范圍。但這樣做具有一個副作用，就是計數(shù)是從零開始生成的，而非從1開始。一旦配置了Observable和測試調(diào)度器，我們立刻做出這樣的斷言，即假定Subscriber不具有值(第15行)且沒有被完成或生成任何的錯誤(第16行)。這是一個完整性測試，因為此時調(diào)度器并沒有被移動，因而沒有任何值被Observable產(chǎn)生或是被Subscriber接收到。
下面將時間向前調(diào)1整秒(第19行)，該操作將會導(dǎo)致Observable生成***個值，這正是隨后的斷言集所要檢查的(第22到24行)。
下面將時間從當(dāng)前時間調(diào)到9秒。需要注意的是，這意味著將時間準(zhǔn)確地調(diào)整為調(diào)度器啟動后的第9秒(并非是向前調(diào)1秒后再向前調(diào)9秒，即調(diào)度器檢查啟動后的第10秒)。換句話說，advanceTimeBy()方法將調(diào)度器的時間調(diào)整為相對于當(dāng)前位置的時間，而advanceTimeTo()以絕對的方式調(diào)整時間。此后我們做出下一輪的斷言(第28到20行)，用于確保所有的數(shù)據(jù)由Observable生成且被Subscriber消費。另一件需要說明的事情就是使用TestScheduler時，真實的時間是立刻發(fā)生調(diào)整的，這著意味著測試并不用實際等待9秒才去完成。
正如你所看到的，該調(diào)度器的使用是非常便利的，僅需將該調(diào)度器提供給正在測試的Observable即可。但是對使用了指定類型調(diào)度器的Observable，該調(diào)度器并不能很好地適用。但是稍等一下，之前我們看到的是如何使用RxJavaHooks切換一個不影響生產(chǎn)代碼的調(diào)度器，而這一次是提供一個代替即刻調(diào)度器的TestScheduler(第13到15行)。我們甚至可以apply定制JUnit規(guī)則同樣的技術(shù)，使之前的代碼可以用更重用的方式予以重寫。首先該新規(guī)則為：
緊接著是實際的測試代碼(在一個新的測試用例類中)，去使用我們的測試規(guī)則：
這樣你就成功地實現(xiàn)了它。使用經(jīng)由RxJavaHooks注入TestScheduler的方法，可在無需更改原始Observable組合的情況下編寫測試代碼，此外它給出了一種在observable自身執(zhí)行期間改變時間、并在特定點上做斷言的方法。在本文中給出的所有這些技術(shù)，應(yīng)該足夠你選擇用來測試RxJava的代碼了。
看完了這篇文章，相信你對“怎么測試RxJava代碼”有了一定的了解，如果想了解更多相關(guān)知識，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝各位的閱讀！
重慶分公司
重慶分公司
