測試 Flutter 應用
瞭解有關不同測試型別的更多資訊以及如何編寫它們。
應用的功能越多，手動測試的難度就越大。自動化測試有助於確保您的應用在釋出前執行正常，同時保持您的功能迭代和 Bug 修復的速度。
自動化測試分為幾類
一般來說，一個測試充分的應用會包含大量的單元測試和元件測試（由程式碼覆蓋率跟蹤），外加足夠的整合測試來覆蓋所有重要的用例。此建議基於這樣一個事實：不同型別的測試之間存在權衡，如下所示。
| 權衡 | 單元 | 小部件 | 整合 |
|---|---|---|---|
| 置信度 | 低 | 較高 | 最高 |
| 維護成本 | 低 | 較高 | 最高 |
| 依賴項 | 少 | 多 | 最多 |
| 執行速度 | 快 | 快 | 慢 |
單元測試
#單元測試用於測試單個函式、方法或類。單元測試的目標是在各種條件下驗證邏輯單元的正確性。被測單元的外部依賴通常會被模擬（Mock）掉。單元測試通常不會讀取或寫入磁碟、渲染到螢幕，也不會接收來自測試執行程序之外的使用者操作。有關單元測試的更多資訊，您可以檢視以下指南，或在終端中執行 flutter test --help。
指南
#元件測試
#元件測試（在其他 UI 框架中稱為“部件測試”）用於測試單個元件（Widget）。元件測試的目標是驗證元件的 UI 外觀和互動是否符合預期。測試元件涉及多個類，並且需要一個提供相應元件生命週期上下文的測試環境。
例如，被測元件應該能夠接收並響應使用者操作和事件、執行佈局並例項化子元件。因此，元件測試比單元測試更全面。然而，與單元測試一樣，元件測試的環境會被替換為一個比完整 UI 系統簡單得多的實現。
指南
#整合測試
#整合測試用於測試完整的應用或應用的很大一部分。整合測試的目標是驗證所有被測元件和服務是否按預期協同工作。此外，您可以使用整合測試來驗證應用的效能。
通常，整合測試在真實裝置或 OS 模擬器（例如 iOS 模擬器或 Android 模擬器）上執行。被測應用通常與測試驅動程式程式碼隔離，以避免結果產生偏差。
Flutter SDK 包含 integration_test 軟體包。但是，此軟體包無法與原生平臺 UI 互動，例如許可權對話方塊、通知或原生平臺檢視。對於需要原生互動的應用，您可以使用 patrol 軟體包，這是一個開源框架，透過原生平臺支援擴充套件了 Flutter 的測試能力。
有關如何編寫整合測試的更多資訊，請參閱整合測試頁面。
指南
#持續整合服務
#持續整合 (CI) 服務允許您在推送新的程式碼變更時自動執行測試。這可以及時反饋程式碼變更是否按預期工作，且沒有引入 Bug。
有關在各種持續整合服務上執行測試的資訊，請參閱以下內容：