type
status
date
slug
summary
tags
category
icon
password
单元测试主要关注应用程序中最小的可测试单元（通常是函数、方法或类），其目的是确保每个单元按预期工作。一般来说，单元测试应该关注以下几个方面：
<ins/>
1. 核心业务逻辑
测试目标：
确保核心功能模块的行为是正确的，尤其是涉及计算、决策和数据处理的部分。
例如：
- 计算类、订单处理、支付逻辑、折扣算法等。
测试内容：
- 函数是否能正确处理预期的输入并返回预期的结果。
- 边界值、特殊情况和异常情况的处理是否正确。
示例代码：
单元测试：
2. 边界条件和异常处理
测试目标：
验证代码在极端或异常输入时的表现，确保代码能够处理错误并给出合理的反馈。
例如：
- 输入为空、负值、零值等。
- 系统资源不足时的处理（例如文件读取错误）。
测试内容：
- 输入为空或非法数据时是否抛出正确的异常。
- 系统边界条件（如最大值、最小值）是否正确处理。
示例代码：
单元测试：
3. 工具函数或库的封装
测试目标：
测试工具函数或库的封装是否能按预期工作。
例如：
- 日期格式化工具、字符串处理工具、数据转换等。
测试内容：
- 函数是否能正确处理正常输入、边界输入以及异常输入。
- 如果依赖于第三方库，则需要验证你封装的代码与第三方库的交互是否正确。
示例代码：
单元测试：
4. 特定功能模块
测试目标：
验证独立的功能模块是否正确执行其任务，尤其是一些封装比较简单的功能，如数据库模型、文件操作等。
例如：
- 计算器、日志记录、文件读取等。
测试内容：
- 模块是否能在独立环境下正确工作。
示例代码：
单元测试：
不适合用单元测试的情况
1. UI 相关代码
为何不适合单元测试：
UI 的布局、组件交互等属于视觉层次的内容，单元测试不适合用于测试 UI 显示、动画效果等。UI 代码应该通过 集成测试 或 UI 测试 来验证。
例如：
- 按钮点击后的 UI 变化，列表的滑动效果等。
适用的替代方案：
- 使用 Flutter 的 widget 测试 来测试 UI 元素是否能正确渲染，确保交互行为符合预期。
示例：
2. 外部依赖（如网络请求、数据库操作）
为何不适合单元测试：
单元测试应该聚焦于 单一功能模块，不涉及外部依赖（如网络请求、数据库操作等）。与外部系统的交互应当通过 集成测试 或 模拟（mock） 来验证。
例如：
- 网络请求、数据库查询、文件操作等。
适用的替代方案：
- 使用 mocking 库（如
mocktail或mockito）来模拟外部依赖，或者使用 集成测试 来测试与外部系统的交互。
示例：
3. 第三方库本身
为何不适合单元测试：
单元测试的目的是验证你自己的代码，而不是验证第三方库的功能。你应当 假设第三方库的功能是正确的，而将注意力集中在如何利用第三方库来实现你的业务需求。
例如：
- 网络请求库、数据库框架、UI 库等。
适用的替代方案：
- 不需要测试第三方库的实现，应该关注如何正确使用这些库，是否能与其他部分协调工作。
总结：
单元测试应测试：
- 核心业务逻辑、计算和算法。
- 边界条件、异常处理。
- 工具类函数。
- 第三方库的封装和交互。
不适合用单元测试的情况：
- UI 相关的测试。
- 依赖外部系统（如网络、数据库等）的代码。
- 第三方库本身。
对于不适合单元测试的情况，可以使用 集成测试 或 UI 测试 来验证应用的整体行为和交互。