Android中的互動測試（Interaction Testing in Android）第二部曲：MVP架構下的互動測試
前情提要
這是Android互動測試系列的第二篇文章，還沒看過前面文章的同學，可以參閱：
簡單來說，現在我們要來開發一個可以顯示溫度資訊的App，每次使用者打開APP時，都可以在螢幕上看見當前的氣溫：
以MVP架構實作
這邊參考Android Architecture Blueprint上MVP架構的做法，先拉出幾個主要的component：
在使用MVP架構開發的這個例子中，MVP三者的代表分別是：
TemperatureDataSource（Model）：負責提供資料，不管資料是從本地、資料庫或API。TemperatureView（View）：負責使用者介面的更新。TemperaturePresenter（Presenter）：負責從Model載入資料，與處理呼叫UI的邏輯。
實作程式碼
MainActivity中保有TemperaturePresenter的instance，每次進入頁面時就會調用TemperaturePresenter.fetchTemperature()。
這邊MainActivity並不關心氣溫是怎麼獲得的，反正將這個工作交給TemperaturePresenter就好，它只負責且在onTemperatureLoaded()被調用的時候，將氣溫顯示在畫面上。（這邊使用TextView的setText()方法來更新溫度）
TemperaturePresenter 的實作為TemperaturePresenterImpl ，當fetchTemperature() 被調用時，會透過dataSource.fetchTemperature()載入溫度資料。（這邊dataSource的實作為TemperatureRepository）
當資料載入完成後，會將得到的溫度透過view.onTemperatureLoaded()這個callback，傳送給MainActivity做後續的UI顯示動作。
TemperatureRepository是TemperatureDataSource的實作。通常Model層（DataSource）的方法實作都會呼叫Retrofit來取得對應的API Service來發送Request，但其實返回的結果一樣都會使用RxJava的Single包裝起來（這邊會返回溫度結果，可能是Float型態，所以就包裝成Single<Float>），所以我們這邊的例子就使用一個假定的數值來代替。
來寫互動測試吧！
我們預期TemperaturePresenter 呼叫fetchTemperature() 方法後，假設過程一切順利（例如call API），TemperatureView 的onTemperatureLoaded() 將會被觸發，進而完成將溫度更新在UI上的動作：
（註：RxSchedulerRule是用來讓RxJava在測試時可以在當前的Thread進行subscribe()，@Mockk 則是MockK的Annotation，用來標記這個變數是Mock起來的）
從上面的例子可以看到，藉由撰寫一個互動測試，我們可以驗證「當我們做了A，應該要觸發B」。互動測試可以幫助我們驗證在程式中物件互動的方式（呼叫方法的方式）、互動的順序甚至互動時傳遞的資料，可以幫助我們進一步的確認程式運作起來是不是跟我們想像中的一樣。
有時間的時候，寫一下測試還是不錯的。畢竟俗話說得好：「程式是照你寫的跑，不是照你想的跑。」（F😭ck~）
