测试 Flutter 应用
了解有关不同测试类型的更多信息以及如何编写它们。
应用的功能越多，手动测试的难度就越大。自动化测试有助于确保您的应用在发布前运行正常，同时保持您的功能迭代和 Bug 修复的速度。
自动化测试分为几类
一般来说，一个测试充分的应用会包含大量的单元测试和组件测试（由代码覆盖率跟踪），外加足够的集成测试来覆盖所有重要的用例。此建议基于这样一个事实：不同类型的测试之间存在权衡，如下所示。
| 权衡 | 单元 | 小部件 | 集成 |
|---|---|---|---|
| 置信度 | 低 | 较高 | 最高 |
| 维护成本 | 低 | 较高 | 最高 |
| 依赖项 | 少 | 多 | 最多 |
| 执行速度 | 快 | 快 | 慢 |
单元测试
#单元测试用于测试单个函数、方法或类。单元测试的目标是在各种条件下验证逻辑单元的正确性。被测单元的外部依赖通常会被模拟（Mock）掉。单元测试通常不会读取或写入磁盘、渲染到屏幕，也不会接收来自测试运行进程之外的用户操作。有关单元测试的更多信息，您可以查看以下指南，或在终端中运行 flutter test --help。
指南
#组件测试
#组件测试（在其他 UI 框架中称为“部件测试”）用于测试单个组件（Widget）。组件测试的目标是验证组件的 UI 外观和交互是否符合预期。测试组件涉及多个类，并且需要一个提供相应组件生命周期上下文的测试环境。
例如，被测组件应该能够接收并响应用户操作和事件、执行布局并实例化子组件。因此，组件测试比单元测试更全面。然而，与单元测试一样，组件测试的环境会被替换为一个比完整 UI 系统简单得多的实现。
指南
#集成测试
#集成测试用于测试完整的应用或应用的很大一部分。集成测试的目标是验证所有被测组件和服务是否按预期协同工作。此外，您可以使用集成测试来验证应用的性能。
通常，集成测试在真实设备或 OS 模拟器（例如 iOS 模拟器或 Android 模拟器）上运行。被测应用通常与测试驱动程序代码隔离，以避免结果产生偏差。
Flutter SDK 包含 integration_test 软件包。但是，此软件包无法与原生平台 UI 交互，例如权限对话框、通知或原生平台视图。对于需要原生交互的应用，您可以使用 patrol 软件包，这是一个开源框架，通过原生平台支持扩展了 Flutter 的测试能力。
有关如何编写集成测试的更多信息，请参阅集成测试页面。
指南
#持续集成服务
#持续集成 (CI) 服务允许您在推送新的代码变更时自动运行测试。这可以及时反馈代码变更是否按预期工作，且没有引入 Bug。
有关在各种持续集成服务上运行测试的信息，请参阅以下内容：