测试 Flutter 应用

应用功能越多，手动测试就越困难。自动化测试有助于在发布前确保应用表现正确，同时保持功能开发与 bug 修复的速度。

自动化测试可分为以下几类：

• A unit test tests a single function, method, or class.

• A widget test (in other UI frameworks referred to as component test) tests a single widget.

• An integration test tests a complete app or a large part of an app.

• 单元测试（unit test）测试单个函数、方法或类。

• widget 测试（widget test，在其他 UI 框架中称为 component test）测试单个 widget。

• 集成测试（integration test）测试完整应用或应用的大部分。

一般而言，经过充分测试的应用会有大量由 代码覆盖率 跟踪的单元测试和 widget 测试，再加上足以覆盖所有重要用例的集成测试。此建议基于不同测试类型之间存在权衡，如下所示。

单元测试（unit test）测试单个函数、方法或类。单元测试的目标是在多种条件下验证逻辑单元的正确性。被测单元的外部依赖通常会 mock 掉。单元测试通常不会从磁盘读写、渲染到屏幕，或从运行测试的进程之外接收用户操作。有关单元测试的更多信息，你可以查看以下食谱，或在终端中运行 flutter test --help。

• 单元测试简介

• 使用 Mockito mock 依赖

widget 测试（widget test，在其他 UI 框架中称为 component test）测试单个 widget。widget 测试的目标是验证 widget 的 UI 外观与交互符合预期。测试 widget 涉及多个类，并需要能提供适当 widget 生命周期上下文的测试环境。

例如，被测 Widget 应能接收并响应用户操作与事件、执行布局并实例化子 widget。因此 widget 测试比单元测试更全面。不过与单元测试类似，widget 测试的环境会被替换为比完整 UI 系统简单得多的实现。

• Widget 测试简介

• 使用 finder 查找 widget

• 在 widget 测试中处理滚动

• 在 widget 测试中点击、拖拽和输入文本

• 测试不同屏幕方向

集成测试（integration test）测试完整应用或应用的大部分。集成测试的目标是验证所有被测 widget 与服务能按预期协同工作。此外，你还可以使用集成测试验证应用性能。

一般而言，_集成测试_在真机或操作系统模拟器上运行，例如 iOS Simulator 或 Android Emulator。被测应用通常与测试驱动代码隔离，以避免结果偏差。

Flutter SDK 包含 integration_test 包。不过该包无法与原生平台 UI 交互，例如权限对话框、通知或 platform view。对于需要原生交互的应用，你可以使用 patrol 包，这是一个扩展开源框架，在原生平台支持下扩展 Flutter 的测试能力。

有关如何编写集成测试的更多信息，请参阅集成测试页面。

• 集成测试概念

• 编写并运行 Flutter 集成测试

• 编写并运行 Patrol 集成测试

• 使用集成测试衡量性能

持续集成（CI）服务允许你在推送新代码变更时自动运行测试。这能及时反馈代码变更是否按预期工作且未引入 bug。

有关在各种持续集成服务上运行测试的信息，请参阅以下内容：

• 使用 fastlane 与 Flutter 进行持续交付

• 在 Appcircle 上测试 Flutter 应用

• 在 Travis 上测试 Flutter 应用

• 在 Cirrus 上测试 Flutter 应用

• 适用于 Flutter 的 Codemagic CI/CD

• 适用于 Patrol 的 Codemagic CI/CD

• 使用 Bitrise 的 Flutter CI/CD