大略的讲，作为一个iOS程序员来说，首先要了解一个叫做MVC的模式。这个模式定义了Cocoa Touch框架的总体结构。在iOS程序中，我们也需要按照这种模式进行界面代码的编写。这样设计出来的类具有较好的结构，且比较适合于做单元测试。

　　然后一定要懂得不停重构代码，这样我们才能使代码不停地改善，不停地变得更加适合单元测试。

　　有一些框架可以帮助大家更好的测试，分别是OCUnit、GTM、GHUnit、CATCH、OCMock，但目前对我来说，OCUnit足够用了。作为苹果官方提供的测试框架，它大的优点是简单易用。

　　三、单元测试实践

　　下面是一些我所理解的单元测试中比较好的实践。

　　顾名思义，单元测试面向的对象是单元，这个专有名词源自编译器领域的术语“编译单元”。在面向过程中，指的是函数，而在面向对象中，指的通常是“类”。因而，每个功能类都应该提供对应的单元测试。

　　实践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{}

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