RecyclerView
能有效處理大量 item 的顯示,其中一項特性是會將捲出螢幕外的 view 回收再利用,螢幕外的 item 並不會出現在 view hierarchy 裡,因此螢幕外的 item 不能用 onView()
來找,再加上 RecyclerView
並非 AdapterView
,所以 onData()
也不適用。
那要怎麼操作或驗證 RecyclerView
某個 item 的內容?而且那個 item 可能在螢幕之外…
當你開始尋找,就已經在前往的路上
RecyclerView
能有效處理大量 item 的顯示,其中一項特性是會將捲出螢幕外的 view 回收再利用,螢幕外的 item 並不會出現在 view hierarchy 裡,因此螢幕外的 item 不能用 onView()
來找,再加上 RecyclerView
並非 AdapterView
,所以 onData()
也不適用。
那要怎麼操作或驗證 RecyclerView
某個 item 的內容?而且那個 item 可能在螢幕之外…
為了縮短測試時間,在實務上會儘可能把 Android framework 的相依性抽離,讓大部份的 production code 可以用 local unit test 在主機的 JVM 上進行測試,少數跟 Android framework 有相依性的 code 才送到 device/emulator 上透過 instrumented test 測試。
If your unit test has NO dependencies or only has SIMPLE dependencies on Android, you should run your test on a local development machine. This testing approach is efficient because it helps you avoid the overhead of loading the target app and unit test code onto a physical device or emulator every time your test is run. Consequently, the execution time for running your unit test is greatly reduced.
若有少量的 Android framework 相依性無法抽離,還是可以搭配 mocking framework (例如 Mockito) 安排 Android framework 該有的行為,讓測試得以進行,否則會有下面的錯誤:
java.lang.RuntimeException: Method xxx in android.xxx.SomeClass not mocked.
At runtime, tests will be executed against a modified version of
android.jar
where all final modifiers have been stripped off. This lets you use popular mocking libraries, like Mockito.
但下面的錯誤,又該如何解釋?
|
|
因緣際會下,今年有機會在 PyCon 2017 進行短講,雖然近期的工作跟 Android 單元測試 (unit testing) 比較相關,但在 Python 的場子分享 Android 似乎不太好 :P
恰巧幾天前從 Google I/O 2017 的一場演說 Test-Driven Development on Android with the Android Testing Support Library 得到不少啟發,尤其整個 TDD workflow 是由 UI testing 驅動的做法,想說就從 Python 的角度切入,看看不同平台的 UI testing 是否有 Python 可以發揮的空間。
先從 UI testing 與 E2E testing 的關係開始說起…
這是 Google I/O 2017 Day 2 (5/18) 一場關於 Android TDD 實務的演說,也是唯一跟 Android 自動化測試比較有關的分享。
整場演說以測試金字塔 (Testing Pyramid) 與 TDD workflow 為主軸,從 large end-to-end (E2E)/UI test 開始驅動 small unit test,再回頭用 hermetic testing 的思維導出中間的 medium integration test。
過程中公佈下一版 Android Testing Support Library (ATSL) 將會有 Android Test Orchestrator 與 Multiprocess Espresso,分別用來消除 large E2E test 間的交互影響、解決 UI 可能執行在多個 process 的問題。
其間最讓人意外的是 Robolectric 似乎開始在 Google 內部受到重視,雖然官方尚未宣稱支持這個專案,但從內部許多專案已經採用、Android CTS 相容性測試已達 70% 看來,正式成為 ATSL 的一員是可以期待的?
connectedAndoidTest
預設會將所有 test 執行在所有連接的 device/emulator 上,若只想執行在某些 device/emulator 上要怎麼做?
就像 #66129 所描述的情節一樣,這樣的需求通常會發生在 build server 上,因為同時連接有許多不同用途的 device/emulator。但這件事有點弔詭,因為相關的討論並不多:
connectedAndoidTest
預設會將所有 test 執行在所有連接的 device/emulator 上,若只想執行某些 test 要怎麼做?
connectedAndroidTest
背後其實也是透過 am instrument
搭配 AndroidJUnitRuner
在 device/emulator 上執行測試:
以 Python binding 為例,若收到一個意味不明的錯誤,例如:
WebDriverException: Message: An unknown server-side error occurred while processing the command.
要如何查出背後的原因?
這個場次由 Dan Hislop 與 Alexander Brauckmann 跟大家分享在 Citrix 是如何進行音質測試 (audio quality testing)。
Citrix 有許多產品跟即時通訊 (real-time communication) 有關,音訊的品質對這類產品至關重要,所以在公司內部提出了一個通用方案,以解決不同產品在音質測試方面共通的問題。
一開始,Alex 問了一句 Can you hear me? 真是絕妙的開場 :)
大概快兩個月前,開始萌生要為 Test Corner 架設一個專屬部落格的念頭,當時的想法是採用 GitHub Pages 並以 testcorner.github.io
做為入口。
用 .github.io
感覺就是潮潮的 (其實是為了跟 Test Corner @ GitHub 接軌),當然有 testcorner.io
更好,只是買 domain 又是一筆費用;目前 Test Corner 完全沒有編列任何預算,事實上是一毛錢都沒有,所有的活動都是靠大家熱情贊助,只好想辦法繼續承襲這個優良的傳統 >_<
直到上個星期,由於 12/01 Test Corner #7 聚會的時間快到了,希望開始為活動留下一點記錄,才開始逼自己要採取一些行動;過去的活動都只有影片、照片分別放在 YouTube 跟 Flickr,沒有再花時間整理,實在有點可惜。
就這樣,在路上遇見了 Hexo …
開機時,kernel 被載入記憶體,接著 module/driver 開始驅動硬體,過程中會輸出大量的訊息 (message);開機完成後,kernel 偶爾也會產生一些有助於診斷問題 (diagnostic) 的 message,例如 I/O 發生問題、USB 裝置熱插拔時。
這些 message 都會被寫入 kernel 內部的 ring buffer (由於 buffer 的大小固定,所以舊的 message 就會被新的 message 推擠掉),dmesg
則可以用來查看目前 kernel ring buffer 的內容:
dmesg [-H]