测试 Flutter 应用
您的应用功能越多，手动测试就越困难。自动化测试有助于确保您的应用在发布前正常运行，同时保持您的功能和错误修复速度。
自动化测试分为几类
一般来说，一个经过良好测试的应用有很多单元和窗口小部件测试，由 代码覆盖率 跟踪，再加上足够的集成测试来涵盖所有重要的用例。此建议基于以下事实：不同类型的测试之间存在权衡，如下所示。
| 单元 | 窗口小部件 | 集成 | |
|---|---|---|---|
| 信心 | 低 | 较高 | 最高 |
| 维护成本 | 低 | 较高 | 最高 |
| 依赖项 | 少 | 更多 | 最多 |
| 执行速度 | 快 | 快 | 慢 |
单元测试
单元测试测试单个函数、方法或类。单元测试的目标是验证逻辑单元在各种条件下的正确性。待测单元的外部依赖项通常会被模拟。单元测试通常不会从磁盘读取或写入磁盘、渲染到屏幕或接收来自运行测试的进程外部的用户操作。有关单元测试的更多信息，你可以查看以下食谱或在你的终端中运行flutter test --help。
食谱
小部件测试
小部件测试（在其他 UI 框架中称为组件测试）测试单个小部件。小部件测试的目标是验证小部件的 UI 看起来和交互符合预期。测试小部件涉及多个类，并且需要一个提供适当小部件生命周期上下文的测试环境。
例如，被测小部件应该能够接收和响应用户操作和事件、执行布局并实例化子小部件。因此，小部件测试比单元测试更全面。但是，与单元测试一样，小部件测试的环境被替换为比成熟的 UI 系统简单的多得多的实现。
食谱
集成测试
集成测试测试一个完整的应用程序或应用程序的很大一部分。集成测试的目标是验证所有被测小部件和服务按预期一起工作。此外，你可以使用集成测试来验证应用程序的性能。
通常，集成测试在真机或操作系统模拟器（如 iOS 模拟器或 Android 模拟器）上运行。被测应用程序通常与测试驱动程序代码隔离，以避免影响结果。
有关如何编写集成测试的更多信息，请参阅集成测试页面。
食谱
持续集成服务
持续集成 (CI) 服务允许你在推送新的代码更改时自动运行测试。这可以及时反馈代码更改是否按预期工作且不会引入错误。
有关在各种持续集成服务上运行测试的信息，请参阅以下内容