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

　　实践1：每个功能类都应提供单元测试，且每一个测试类，只依赖于其要测试的受测类。使用伪造对象可以避免对其他类的依赖。

　　解释：保证一个测试类只关注一个被测类，当测试不通过时，就能迅速的定位到是谁发生了错误，而不会受到其他类的干扰。

　　简单的数据类等可以不提供，但是要保证该测试的都要覆盖到。并不存在一种合适的度量指标可以量化地判断某种单元测试方案是否成功。常用的标准(代码覆盖率和成功执行的测试用例数)都可以在受测软件的质量不变的情况下人为的修改(作假)。当然，在无法确保程序员素质的情况下，作为没有办法的办法，使用这种标准也是可以的(或者无奈的说，必须的)。单元测试需要程序员自己把关，关注哪些功能确实需要测试覆盖。这也就是前面所说的一些程序员不相信单元测试可以提高生产率的理由--它更多的依赖于程序员的素质，这是没有保证的。但同样的，由于敏捷是一种以人为本的思想实践，因而这种行为似乎又是一种必然。

　　实践1.1：使用伪造类避免对其他类的依赖。

　　解释：避免依赖的一种手段。

　　例如，某个被测的方法声明是这样的：

　　-(void)xxxx:(Person *)person;

　　如果测试时传入Person的话，就造成了测试类依赖于两个类。当由于person中的错误引发测试不通过时，就不能迅速的定位到受测类中是否有问题。遇到这种情况，就可以使用伪造类。假如方法中只使用了person的一个属性name，那么可以将方法名重构为

　　-(void)xxxx:(id)person;(此处id有待商榷，只是这样做最简单)

　　然后在单元测试的target中添加只包含name属性的fakePerson来作为伪造类。这样，一旦发生错误就可以迅速的推测出错误的来源。

　　实践1.2：使用伪造环境避免其他环境的干扰。

　　解释：适合于异步的方法测试。

　　很经常遇到的一种情况是测试有网络环境的代码。由于异步的存在，这会造成测试代码不好写。一种简单的解决方法是，我们假定网络一定是通畅的，则我们测试的代码将分为两部分，即拼装发送功能和接收解析功能。假如发送和接收功能各自都能通过测试，那么我们大约可以确定这个异步方法的正确性。另一种方法是使用GHUnit，它支持异步代码的测试。

　　实践2：测试用例(方法)名应该是自解释的且是独立的。

　　解释：基本功。

　　如果被测试类的名称是XXX，那么测试类可以命名为XXXTests。而对于其中要测试的功能，命名应该是自解释的。这可以在发现错误时尽快的定位问题所在。例如，如果某个属性obj应该是非空的，那么我们可以将其命名为：

　　-(void)testObjNotNil{}

　　每个方法目标应该是单一的，大多数情况下每个方法内都只有一个断言语句;方法不应该依赖于其他方法的结果作为输入，保证原子性。

　　实践3：断言语句需要解释测试者的意图。

　　解释：基本功

　　每种单元测试框架都提供了很多断言语句，从根本上来说它们都是一样的。但是测试者需要根据自己的目的选择适当的语句，这样才可以让别人阅读测试代码时理解用例设计的目的。例如对于STAssertNil和STAssertNotNil等等。

　　实践4：判断某个意图有没有达到的很好的方法是检测方法影响的数据有没有合理的变化。

　　解释：基本功

　　由于单元测试是使用断言语句来做判断的，因而最容易做的就是判断数据的变化。这也就限定了单元测试能测试的方法范围，即引起数据变化的方法。对于一些纯展示的方法，例如播放一段特效，这种方法是无法靠单元测试来进行约束的。测试数据的特性包括取值范围(int、float等)，排列顺序(NSArray等)，类型等等。

　　实践5：运用重构的手段使方法变得易于被测试。

　　解释：单元测试是保障重构安全的手段，重构也可以使代码易于被测试。

　　什么样的代码是容易进行单元测试的?最简单的一点就是，每个被测方法都应该是功能单一的。当然，这也是代码规范中应该做到的。方法的功能单一，则测试方法的断言也会比较好确定。如果你发现某个方法很难进行测试，则就应该对这个方法进行拆分重构。

　　实践5.1：面向抽象设计类之间的关系。

　　解释：利于伪造类的实现。

　　类之间通讯如果依赖于抽象(接口)，则可以较容易的使用伪造类。参照实践1.1。

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