官方文檔html
隨着你的應用程序功能越多,手動測試就愈來愈難。自動測試有助於確保你的應用程序在發佈前正確運行,同時保留你的功能和加快bug修復速度。git
自動化測試分爲如下幾類:github
通常來講,一個通過良好測試的應用程序有許多單元和widget測試,經過代碼覆蓋率來跟蹤,加上足夠的集成測試來覆蓋全部重要的用例。 這個建議是基於這樣一個事實,即不一樣類型的測試之間存在着權衡,以下所示。redux
單元測試 | Widget測試 | 集成測試 | |
---|---|---|---|
可信度 | 低 | 高 | 最高 |
維護成本 | 低 | 高 | 最高 |
依賴性 | 不多 | 多 | 最多 |
執行速度 | 快 | 慢 | 最慢的 |
單元測試測試單個函數、方法或類。 單元測試的目標是在各類條件下驗證邏輯單元的正確性。 被測試單元的外部依賴項一般被模擬出來。 單元測試一般不從磁盤讀取或寫入,也不從運行測試的進程外部接收用戶操做。app
Widget測試(在其餘被稱爲組件測試的UI框架中)測試單個Widget。Widget測試的目標是驗證Widget的UI是否按預期進行查看和交互。測試一個Widget涉及多個類,而且須要提供一個BuildContext用來給Widget提供上下文環境。gitlab
例如,被測試的Widget應該可以接收和響應用戶操做和事件,執行佈局,並實例化child Widgets。所以,Widget測試比單元測試更全面。可是,與單元測試同樣,Widget測試的環境被一個比完整的UI系統簡單得多的實現所取代。佈局
Widget測試介紹的翻譯post
集成測試測試一個完整的應用程序或應用程序的大部分。集成測試的目標是驗證全部被測試的Widget和服務是否按預期正常工做。此外,您可使用集成測試來驗證應用程序的性能。 一般,集成測試在真實設備或模擬器上運行,如iOS模擬器或Android模擬器。測試中的應用程序一般與測試驅動程序代碼隔離,以免結果出現誤差。
持續集成(CI)服務容許您在推送新代碼更改時自動運行測試。這能夠及時反饋代碼更改是否按預期工做,而且不會引入bug。 有關在各類持續集成服務上運行測試的信息,請參見如下內容:
.gitlab-ci.yml
文件。您能夠在flutter_redux庫中找到一個示例。