跳至主要內容

測試 Flutter 應用程式

您的應用程式擁有的功能越多,手動測試就越困難。自動化測試有助於確保您的應用程式在發布前能正確執行,同時保持您的功能開發和錯誤修復速度。

自動化測試可分為幾個類別

  • 單元測試 會測試單一函式、方法或類別。
  • 元件測試(在其他 UI 框架中稱為元件測試)會測試單一元件。
  • 整合測試 會測試完整的應用程式或應用程式的大部分。

一般來說,一個經過良好測試的應用程式會包含許多單元測試和元件測試,並透過程式碼覆蓋率追蹤,再加上足夠的整合測試來涵蓋所有重要的使用情境。此建議的依據是不同類型的測試之間存在權衡取捨,如下所示。

權衡取捨單元元件整合
信心程度較高最高
維護成本較高最高
依賴性較多最多
執行速度

單元測試

#

單元測試會測試單一函式、方法或類別。單元測試的目標是驗證邏輯單元在各種條件下的正確性。被測試單元的外部依賴項通常會被模擬 (mock out)。單元測試通常不會從磁碟讀取或寫入磁碟、呈現到螢幕,或接收來自測試執行程序之外的使用者操作。如需更多關於單元測試的資訊,您可以查看以下範例或在終端機中執行 flutter test --help

範例

#

Widget 測試

#

元件測試(在其他 UI 框架中稱為元件測試)會測試單一元件。元件測試的目標是驗證元件的 UI 外觀和互動是否符合預期。測試元件涉及多個類別,並需要提供適當元件生命週期環境的測試環境。

例如,被測試的元件應能夠接收並回應使用者操作和事件、執行版面配置,以及實例化子元件。因此,元件測試比單元測試更全面。但是,與單元測試一樣,元件測試的環境會被一個比完整的 UI 系統簡單得多的實作所取代。

範例

#

整合測試

#

整合測試會測試完整的應用程式或應用程式的大部分。整合測試的目標是驗證所有被測試的元件和服務是否能如預期般協同運作。此外,您可以使用整合測試來驗證您的應用程式效能。

一般來說,整合測試會在真實裝置或 OS 模擬器(例如 iOS 模擬器或 Android 模擬器)上執行。被測試的應用程式通常會與測試驅動程式碼隔離,以避免扭曲結果。

如需更多關於如何編寫整合測試的資訊,請參閱整合測試頁面

範例

#

持續整合服務

#

持續整合 (CI) 服務允許您在推送新的程式碼變更時自動執行測試。這可以及時回饋程式碼變更是否如預期般運作,並且不會引入錯誤。

如需更多關於在各種持續整合服務上執行測試的資訊,請參閱以下內容