开发阶段的自我检查 之 单元测试

开发阶段的自我检查 之 单元测试

Q:开发阶段我们可以进行哪些自我检查呢?

🌇 例如:刚写好一个轮播图组件

✅ 我们会造一些轮播图的数据 > 跑一把 看看效果

✅ 修改一下数据 只有一张图片 > 重新加载 看下效果

✅ 数据为空 > 重新加载 看下效果

✅ 换用不同尺寸的图片 > 再次进入 看下效果

是的 在开发阶段我们经常会做代码的自我检查

A:从开发的过程来分 我们可以把开发阶段的自我检查划分为：

test func > test class > test service || test UI

相应的我们可以在开发阶段进行:

func test > class test > service test || UI test

从后往前看 我们是否可以更系统的进行开发阶段的自我检查:

1⃣️UI Test我们做的很多 => 开发完毕 > mock数据 > 人肉看一下不同数据时 UI和功能是否正常

2⃣️service test？=> 服务端通过接口测试做的比较多

3⃣️ 再往前看 class test & func test => 不易触及 进行自我检查的次数比较少

---

当你的输出是一个App ➡️ 我们可以通过UI进行直接的交互

当你的输出是一个Service ➡️ 我们可以通过接口进行直接的交互

当你的输出是一个Class or function ➡️ 我们可以通过什么进行直接的交互呢?

如果你是AFNetworking的作者 如何进行测试？

1⃣️ 写一个Example App 通过人机交互的方式 进行每一项功能的验证？

2⃣️ 通过单元测试框架 调用每一个待测试的方法 进行功能的验证

今天我们的主题就是这里

通过单元测试 我们可以方便系统的进行 func test & class test

从而可以更系统的进行开发阶段的自我检查 交付测试团队更加健壮的产出

什么是单元测试呢?

1⃣️ 最小可测单元_测试自己写的对外提供功能or计算过程

2⃣️ 不是为了发现bug，是为了提高开发效率，为了我们代码健康的可持续发展

🌰 一些调试很久的疑难问题 往往根源是一些简单低级的小错误引起的

单元测试的优缺点

优点：

1⃣️ 单元测试能保证在加入新功能或修改旧功能时代码的正确性

2⃣️ 单元测试保证在整个开发流程中代码都会被测试，更容易及早发现问题，降低风险

场景:

1⃣️ 发版前修改了基础组件的某个功能 ➡️ 通过单元测试 可以方便低成本的进行回归测试

2⃣️ 代码重构后 ➡️ 功能影响的摸底与评估

3⃣️ 开发过程中 直接测试某个方法 ➡️ 无需build & run整个工程

缺点：

单元测试不能减少研发的代码量，反而会花费很多精力在编写单元测试上，增加了开发成本，而且对开发人员的要求也会更高

单元测试由谁来写?

最好是开发者本人

如何写单元测试?

每一个Test Case的写法有三个步骤：①Mock对象，准备测试数据。②调用要测试的目标API。③验证输出和行为是否正确

iOS项目如何进行单元测试呢?

1⃣️ XCTest in XCode

2⃣️ Kiwi for OC (3rd framework)

3⃣️ Quick for Swift or OC (3rd framework)

XCTest Demo:

TestCaseWritenByXCTest

Quick Demo:

TestCaseWritenByQuick

单元测试应用案例(学习样本)

XCTestWorkInAF QuickWorkinRAC

单元测试落地计划:

1⃣️ 基础服务 覆盖

2⃣️ 公共组件 覆盖

3⃣️ 基础业务viewModel 覆盖

4⃣️ 重要业务viewModel 覆盖

参考资料:

1⃣️ iOS单元测试基本介绍

2⃣️ Quick

3⃣️ Quick使用配置