iOS开发进阶之单元测试(3)

　　实践6：运用自上而下的方式构建类。

　　解释：自上而下的方式可以使类的功能明确，类的构成将会清晰紧凑，不会出现一些废方法。

　　先确定类需要负担的责任，以此来确定类具有的公有方法以及属性。通过重构将公有方法中的代码转化为私有方法，以使方法尽量短小紧凑。

　　实践6.1：应对所有暴露的属性和方法提供测试，私有方法则不必。

　　解释：如果运用自上而下的方式构建类，则理论上私有方法应该都是公有方法重构而得到的。实际上测试公有方法时这些私有方法都应该被测试到了。而且，由于私有方法相对公有方法来说发生变动的可能性很大，会造成不必要的修改测试代码的成本。

　　回调方法不属于私有方法，也需要进行测试。

　　实践6.2：回调方法的测试方法是直接调用。

　　解释：基本功

　　由于回调方法一般是异步和不可触发的(按正常流程)，例如网络事件的返回和按下按钮的触发事件。因而，测试的时候要直接调用来对其流程进行检测。例如某个按钮的touch up inside事件：

　　-(void)buttonPressed:(id)sender;

　　可以根据方法中用到的方法、属性伪造一个FakeButton按钮作为参数传递进行测试。

　　实践6.3：测试私有的方式，KVC、子类化和类别。

　　解释：基本功。

　　遇到需要通过验证私有数据才能编写的测试时，可以考虑使用KVC和子类化。子类继承于被测类，只包含于单元测试target，其作用就是在不该变受测类的情况下，使受测类具有某些易于被测的能力。

　　实践7：变化需要新测试的支持。

　　解释：保证测试的覆盖度。

　　就像敏捷中提到的“改变需要抽象”一样，在测试中改变需要新的测试。当然，度依然由程序员自己掌控。

　　四、一般流程

　　使用OCUnit最大的好处就是流程非常的简单，简单到让你觉得非常愉悦。由于有XCode的支持，添加测试变得异常简单。只要在新建工程时勾选“Include Unit Tests”，就会自动的加入一个示例。然后再需要添加新的单元测试时，新建一个“Objective-C test case class”就可以了。

　　测试文件中，只要知道setUp是初始化的地方，tearDown是结束清理的地方，而且它们在每个用例方法执行时都会重新执行--这保证了测试用例的原子性。然后知道每个测试用例都是以test作为前缀的，并且无返回值。然后在方法中编写断言语句就可以了。输入STAssertxxxxx就可以看到它们的联想提示。编写完成后，执行菜单 Product->Test，单元测试就完成了!

　　五、测试驱动(TDD)

　　敏捷当中提到了TDD这种开发方式。TDD的主旨是使开发者对其编写的代码更有信心，使开发者修改代码时心里更加踏实。对于其总结，还是引用原文比较妥当：“测试驱动开发的妙处即在于，它以需求为引领，通过测试的形式，来指导开发者进行软件的设计与架构，并编写出最为精炼的代码，使得测试用例运行通过。经过适当的重构之后，测试用例与产品代码可达到较为健康的状态。”也就是上面提到的，通过自上而下的形式设计类，通过单元测试来不停地审视和重构类，从而达到代码的健康。

　　如果在代码写完之后在编写单元测试，那么就体现不出这种模式的好处了。这就好像写完代码再补文档一样，没有什么意义。测试应该在代码开始之前，或者在代码编写中不停地进行编写更新，这样才能使代码不停进步。这也正是TDD的意思。

　　六、总结

　　单元测试的代码如此简单，但是想写好单元测试却并不是一件简单的事情。它需要程序员比较深的功底。由于个人水平所限，有一些东西说的比较啰嗦。把复杂问题简单化是本事，任重而道远。希望大家可以在日常开发中运用好这种简洁高效的技术。

原文转自：http://www.uml.org.cn/Test/201306072.asp