通常一个应用的功能越多，手工测试就越困难。自动化测试在发布之前运行，有助于保证我们应用的稳定性和功能的完整性，并且可以快速修复问题。
自动化测试可分为以下几类：
单元测试 测试单一的函数，方法或类。
widget 测试（在其他 UI 框架中指 组件测试）测试单一的 widget 。
集成测试 测试一个完整的应用或者一个应用的大部分功能。
一般来说，在自动化测试方面做的比较好的应用会有许多单元测试和 widget 测试，并且使用代码覆盖率进行追踪，还会有足够的集成测试来覆盖所有的重要使用场景。这样做是因为不同类型的测试之间需要权衡，如下所示：
| 单元测试 | widget 测试 | 集成测试 | |
|---|---|---|---|
置信度 |
低 |
较高 |
最高 |
维护成本 |
低 |
较高 |
最高 |
依赖程度 |
少 |
较多 |
最多 |
执行速度 |
快 |
较慢 |
慢 |
1. 单元测试
单元测试 测试单一的函数，方法或类。单元测试的目标是验证逻辑单元在各种条件下的正确性。被测试单元的外部依赖通常需要 模拟。单元测试通常不会读写磁盘，将数据渲染到屏幕，也不会从运行测试进程的外部去接收用户的操作。
1.1 更多信息
2. widget测试
Widget 测试（在其他 UI 框架中指 组件测试）是用来测试单一的 widget， widget 测试的目标是验证 widget 的 UI 表现和交互行为是否符合预期。测试一个 widget 涉及多个类，并且测试环境需要提供具有 widget 生命周期的上下文。
例如，被测试的 widget 可以接收和响应用户操作和事件，进行布局，并实例化子 widget 。所以，widget 测试比单元测试更全面。但是，就像单元测试一样，widget 测试环境实现上比成熟的 UI 系统简单得多。
2.1 更多信息
3. 集成测试
集成测试 测试一个完整的应用或者一个应用的大部分功能。集成测试的目标是验证正在测试的所有 widget 和服务是否按照预期的方式一起工作。此外，还可以使用集成测试来验证应用的性能。
通常情况下，一个 集成测试 运行在真机或 OS 模拟器上，如 iOS 模拟器 (iOS Simulator) 或 Android 模拟器 (Android Emulator) 。测试中的应用通常与测试驱动程序代码隔离，以避免结果出现偏差。
3.1 更多信息
4. 持续集成服务
持续集成 (CI) 服务允许我们在推送新代码（代码变更）时自动运行测试。当代码变更后，会立即收到关于代码是否仍按预期工作、是否引入新问题的反馈。
有关各种持续集成服务的信息，参考如下：
Flutter 里的持续部署
使用 Travis 测试 Flutter 应用
使用 Cirrus 测试 Flutter 应用
GitLab 持续集成（GitLab CI/CD）。需要创建，并且配置 .gitlab-ci.yml 文件。可以在 flutter_redux 库中 找到例子。
Flutter 中的 Codemagic 持续集成/持续交付
使用 Bitrise 进行 Flutter 持续集成/持续交付