很多iOS程序员小伙伴们认为iOS客户端应用的测试难写。出现这种情况的原因是没有找到合适的测试策略。
产品代码设计
为了让代码可测试，我们需要对其进行一些设计。
问题
因为苹果一直很推荐MVC的编程框架，我们的ViewController很容易承担起了业务逻辑和显示逻辑的处理。因此MVC很容易就成了Massive ViewController。当大量的代码就集中在了ViewController当中，耦合自然就高了，测试的难度也就急剧上升。
解决方法
将业务逻辑代码从ViewController当中移除出来。那么ViewController当中就只有了显示逻辑。这在一定程度上也解耦了代码。
如何將业务逻辑代码从ViewController当中分离出来呢？一种方式是使用MVVM的设计。將业务逻辑代码封装在ViewModel当中。
那么，我们可以分别测试业务逻辑代码和显示逻辑代码。
测试类型
测试不可能覆盖所有的产品代码，那我们的目的是尽可能的覆盖复杂的、更可能出错的产品代码逻辑。
单元测试
单元测试，顾名思义，就是要以软件设计的最小模块为一个单元进行测试。而在iOS开发当中，我们的最小模块应该是一段业务逻辑或者是一个页面显示逻辑。因此，我们將业务逻辑和显示逻辑的测试都纳入到单元测试中。
业务逻辑测试
业务逻辑测试测暴露出来的方法。我们构建出需要输入的参数，验证期望的返回值。
测试特点：
- 关注点集中
每一个测试就仅仅是为了测试目标方法和其内部的私有方法。 - 容易编写
只需要构建需要的不同参数，然后测试相应的各种返回值即可。 - 快速定位错误
一旦测试失败，我们很容易的就能得到期望值和实际值。并且能够设置断点进行调试追踪。 - 测试速度快
测试仅仅是生成对象然后对其目标方法进行调用，整个过程快速稳定。
以上特点决定了这类测试的数量一定是最多的。并且测试的代码集中在测试各个ViewModel的方法。
显示逻辑测试
显示逻辑测试最后页面呈现的样式。我们可以构建出页面需要的ViewModel，传给其对应的View。将对应的View生成图片，保证每次生成的图片是一样的。
测试特点：
- 测试粒度较大
因为是生成图片的对比，我们一般构建整个ViewModel用来生成一个View，来对比截图。因此测试的方法不在是针对某一个方法。针对的是整个View的显示逻辑的正确性。 - 无法驱动开发
因为我们需要生成截图，我们无法在功能完成之前就写出对应的测试。这种测试更多的是保证显示逻辑的正确性。无法驱动开发。 - 无法精确定位错误
由于我们最后仅仅是对于每次测试生成的截图和预先生成的截图进行对比。当测试失败的时候，我们并不能定位错误代码的位置。仅仅能根据测试生成的截图进行推测。 - 测试速度较快
虽然是截图的比较，但是可以通过内存的比较来较快速的完成。因此测试速度依然是较快的。
以上特点决定了这类型的测试数量会远远低于业务逻辑测试。其测试粒度较大。但是其测试覆盖率也很容易做的很大。
功能测试
单元测试是静态的测试。我们现在来考虑模拟用户操作的的测试。这样的测试我们称为功能测试。
测试的目标为程序对用户操作的响应的正确性。
我们的应用在页面跳转的时候，通常伴随着后台数据的请求。如果这时候我们使用真是的服务器响应请求，通常会遇到两个问题。
- 不能脱机测试。
- 依赖于服务器的稳定性。
通常的解决方案是使用mock的API请求。
测试特点：
- 测试速度慢
页面跳转动画，测试框架，控件检测等特点导致测试一个feature的时间会非常的长。导致跑一次测试需要的时间会非常长。 - 动态测试
功能测试模拟用户使用，是抛开代码的黑盒的动态的测试。关注的点是业务流程和用户操作的正确响应。 - 无法精确定位错误
因为是黑盒测试，我们只能看到测试失败后的结果。从而推测可能出错的地方。
这类测试的数量是不多的，但是却可以覆盖大部分的业务流程和用户操作。其测试覆盖率也很容易做的很高。
回归测试
回归测试和功能测试几乎相同，仅仅把mock数据替换成真实数据。
测试特点：
- 集成测试
使用真实数据，可以发现真实环境中出现的问题。 - 高效率
代替手动测试，大大提高回归效率。 - 不稳定
替换真实数据后，测试的稳定性还会受到网络情况的影响。大大增加了不确定性，因为需要人去检查失败的结果。
测试框架推荐
- 业务逻辑测试
- 显示逻辑测试
- 功能测试
- calabash-cucumber
网友评论