這一篇開始讓TDD在Android實踐。
30天的發文到了最後一天了,這是第二次參加鐵人賽,每次參賽都抱持著要利用這個機會把一直想學會的學起來。去年寫了Android animation 30天上手,從開賽的一個月前準備。這次TDD則花了更長的時間提早準備。用了4個主題來介紹:「單元測試基本概念」、「在Android 上進行單元測試」、「使用MVP、MVVM 架構提高可測試性」、「TDD 測試驅動開發」,其中花了最多的時間在想要用怎樣的範例才能讓大家容易理解。在開賽後就更累了,下班回家就是準備鐵人賽文章,晚睡早起,也幸好有太太的包容,完賽了很累但也很值得。
這一篇我們要來小結一下TDD。
TDD 測試驅動開發(Test-driven development),是一種「先寫測試再開發程式」的開發技巧。
步驟:1.紅燈:先寫失敗的測試案例。2.綠燈:快速實作功能讓測試案例通過。3.重構:在不改變功能的前提下,修改程式碼。改善可維護性。
MVVM與MVP的TDD只有ViewModel的地方有不一樣,
TDD 測試驅動開發(Test-driven development),是一種「先寫測試再開發程式」的開發技巧。先寫測試除了確保測試程式碼的運作,更有助於在開發初期就先想清楚需求是什麼,先弄清楚程式介面如何設計。
步驟:1.先寫失敗的測試案例。2.快速實作功能讓測試案例通過。3.重構:在不改變功能的前提下,修改程式碼。改善可維護性。
在第一篇,我們曾提到Android測試的其中一個困難點在於Activity經常有著過多的邏輯。這個單元分別介紹了在MVP(Model View Presenter)、MVVM(Model View ViewModel)這兩種架構。這兩種架構都是為了簡化view與商業邏輯資料處理互相溝通的邏輯,讓不同的元件拆得更乾淨,減少彼此的耦合。在這個單元的小結就來整理一下兩個架構的差異。
在上一篇呼叫WebAPI的範例,我們使用了Rxjava,這一篇要再深入介紹在使用Rxjava時應該怎麼測試。
在之前的範例,我們都是在Repository模擬呼叫WebAPI來取得資料,現在要實際接上一個WebAPI來看看應該怎麼測試。要測試有沒有真的呼叫到WebAPI,那這會是一個e2e的測試…
這篇要介紹Kotlin的輕量級依賴注入框架Koin。
為了在單元測試解除外部相依,我們使用了依賴注入的方式,例如在MVP的架構下,Activity需要在初始化Repository時注入Presenter。這將造成Activity的程式變得複雜。一般情況,Activity應該不需要知道Repository的。
class MainActivity : AppCompatActivity() {
介紹完了 DataBinding、ViewModel、LiveData,可以開始來寫MVVM的單元測試了。
先看ProductionCode,getProduct…