Kiwi
测试驱动开发(Test Driven Development，以下简称TDD)是保证代码质量的不二法则，也是先进程序开发的共识。Apple一直致力于在iOS开发中集成更加方便和可用的测试，在Xcode 5中，新的IDE和SDK引入了XCTest来替代原来的SenTestingKit，并且取消了新建工程时的“包括单元测试”的可选项（同样待遇的还有使用ARC的可选项）。新工程将自动包含测试的target，并且相关框架也搭建完毕，可以说测试终于摆脱了iOS开发中“二等公民”的地位，现在已经变得和产品代码一样重要了。我相信每个工程师在完成自己的业务代码的同时，也有最基本的编写和维护相应的测试代码的义务，以保证自己的代码能够正确运行。更进一步，如果能够使用TDD来进行开发，不仅能保证代码运行的正确性，也有助于代码结构的安排和思考，有助于自身的不断提高。我在最开始进行开发时也曾对测试嗤之以鼻，但后来无数的惨痛教训让我明白那么多工程师痴迷于测试或者追求更完美的测试，是有其深刻含义的。如果您之前还没有开始为您的代码编写测试，我强烈建议，从今天开始，从现在开始（也许做不到的话，也请从下一个项目开始），编写测试，或者尝试一下TDD的开发方式。
而Kiwi是一个iOS平台十分好用的行为驱动开发(Behavior Driven Development，以下简称BDD)的测试框架，有着非常漂亮的语法，可以写出结构性强，非常容易读懂的测试。因为国内现在有关Kiwi的介绍比较少，加上在测试这块很能很多工程师们并没有特别留意，水平层次可能相差会很远，因此在这一系列的两篇博文中，我将从头开始先简单地介绍一些TDD的概念和思想，然后从XCTest的最简单的例子开始，过渡到Kiwi的测试世界。在下一篇中我将继续深入介绍一些Kiwi的其他稍高一些的特性，以期更多的开发者能够接触并使用Kiwi这个优秀的测试框架。
什么是TDD，为什么我们要TDD
测试驱动开发并不是一个很新鲜的概念了。软件开发工程师们（当然包括你我）最开始学习程序编写时，最喜欢干的事情就是编写一段代码，然后运行观察结果是否正确。如果不对就返回代码检查错误，或者是加入断点或者输出跟踪程序并找出错误，然后再次运行查看输出是否与预想一致。如果输出只是控制台的一个简单的数字或者字符那还好，但是如果输出必须在点击一系列按钮之后才能在屏幕上显示出来的东西呢？难道我们就只能一次一次地等待编译部署，启动程序然后操作UI，一直点到我们需要观察的地方么？这种行为无疑是对美好生命和绚丽青春的巨大浪费。于是有一些已经浪费了无数时间的资深工程师们突然发现，原来我们可以在代码中构建出一个类似的场景，然后在代码中调用我们之前想检查的代码，并将运行的结果与我们的设想结果在程序中进行比较，如果一致，则说明了我们的代码没有问题，是按照预期工作的。比如我们想要实现一个加法函数add，输入两个数字，输出它们相加后的结果。那么我们不妨设想我们真的拥有两个数，比如3和5，根据人人会的十以内的加法知识，我们知道答案是8.于是我们在相加后与预测的8进行比较，如果相等，则说明我们的函数实现至少对于这个例子是没有问题的，因此我们对“这个方法能正确工作”这一命题的信心就增加了。这个例子的伪码如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
//Product Code add(float num1, float num 2) {...} //Test code let a = 3; let b = 5; let c = a + b; if (c == 8) { // Yeah, it works! } else { //Something wrong! } |
当测试足够全面和具有代表性的时候，我们便可以信心爆棚，拍着胸脯说，这段代码没问题。我们做出某些条件和假设，并以其为条件使用到被测试代码中，并比较预期的结果和实际运行的结果是否相等，这就是软件开发中测试的基本方式。
为什么我们要test
而TDD是一种相对于普通思维的方式来说，比较极端的一种做法。我们一般能想到的是先编写业务代码，也就是上面例子中的add方法，然后为其编写测试代码，用来验证产品方法是不是按照设计工作。而TDD的思想正好与之相反，在TDD的世界中，我们应该首先根据需求或者接口情况编写测试，然后再根据测试来编写业务代码，而这其实是违反传统软件开发中的先验认知的。但是我们可以举一个生活中类似的例子来说明TDD的必要性：有经验的砌砖师傅总是会先拉一条垂线，然后沿着线砌砖，因为有直线的保证，因此可以做到笔直整齐；而新入行的师傅往往二话不说直接开工，然后在一阶段完成后再用直尺垂线之类的工具进行测量和修补。TDD的好处不言自明，因为总是先测试，再编码，所以至少你的所有代码的public部分都应该含有必要的测试。另外，因为测试代码实际是要使用产品代码的，因此在编写产品代码前你将有一次深入思考和实践如何使用这些代码的机会，这对提高设计和可扩展性有很好的帮助，试想一下你测试都很难写的接口，别人（或者自己）用起来得多纠结。在测试的准绳下，你可以有目的有方向地编码；另外，因为有测试的保护，你可以放心对原有代码进行重构，而不必担心破坏逻辑。这些其实都指向了一个最终的目的：让我们快乐安心高效地工作。
在TDD原则的指导下，我们先编写测试代码。这时因为还没有对应的产品代码，所以测试代码肯定是无法通过的。在大多数测试系统中，我们使用红色来表示错误，因此一个测试的初始状态应该是红色的。接下来我们需要使用最小的代价（最少的代码）来让测试通过。通过的测试将被表示为安全的绿色，于是我们回到了绿色的状态。接下来我们可以添加一些测试例，来验证我们的产品代码的实现是否正确。如果不幸新的测试例让我们回到了红色状态，那我们就可以修改产品代码，使其回到绿色。如此反复直到各种边界和测试都进行完毕，此时我们便可以得到一个具有测试保证，鲁棒性超强的产品代码。在我们之后的开发中，因为你有这些测试的保证，你可以大胆重构这段代码或者与之相关的代码，最后只需要保证项目处于绿灯状态，你就可以保证代码没重构没有出现问题。
简单说来，TDD的基本步骤就是“红→绿→大胆重构”。
使用XCTest来执行TDD
Xcode 5中已经集成了XCTest的测试框架（之前版本是SenTestingKit和OCUnit），所谓测试框架，就是一组让“将测试集成到工程中”以及“编写和实践测试”变得简单的库。我们之后将通过实现一个栈数据结构的例子，来用XCTest初步实践一下TDD开发。在大家对TDD有一些直观认识之后，再转到Kiwi的介绍。如果您已经在使用XCTest或者其他的测试框架了的话，可以直接跳过本节。
首先我们用Xcode新建一个工程吧，选择模板为空项目，在Product Name中输入工程名字VVStack，当然您可以使用自己喜欢的名字。如果您使用过Xcode之前的版本的话，应该有留意到之前在这个界面是可以选择是否使用Unit Test的，但是现在这个选框已经被取消。
新建工程
新建工程后，可以发现在工程中默认已经有一个叫做VVStackTests的target了，这就是我们测试时使用的target。测试部分的代码默认放到了{ProjectName}Tests的group中，现在这个group下有一个测试文件VVStackTests.m。我们的测试例不需要向别的类暴露接口，因此不需要.h文件。另外一般XCTest的测试文件都会以Tests来做文件名结尾。
Test文件和target
运行测试的快捷键是⌘U（或者可以使用菜单的Product→Test），我们这时候直接对这个空工程进行测试，Xcode在编译项目后会使用你选择的设备或者模拟器运行测试代码。不出意外的话，这次测试将会失败，如图：
失败的初始测试
VVStackTests.m是Xcode在新建工程时自动为我们添加的测试文件。因为这个文件并不长，所以我们可以将其内容全部抄录如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
#import <XCTest/XCTest.h> @interface VVStackTests : XCTestCase @end @implementation VVStackTests - (void)setUp { [super setUp]; // Put setup code here. This method is called before the invocation of each test method in the class. } - (void)tearDown { // Put teardown code here. This method is called after the invocation of each test method in the class. [super tearDown]; } - (void)testExample { XCTFail(@"No implementation for \"%s\"", __PRETTY_FUNCTION__); } @end |
可以看到，VVStackTests是XCTestCase的子类，而XCTestCase正是XCTest测试框架中的测试用例类。XCTest在进行测试时将会寻找测试target中的所有XCTestCase子类，并运行其中以test开头的所有实例方法。在这里，默认实现的-testExample将被执行，而在这个方法里，Xcode默认写了一个XCTFail的断言，来强制这个测试失败，用以提醒我们测试还没有实现。所谓断言，就是判断输入的条件是否满足。如果不满足，则抛出错误并输出预先规定的字符串作为提示。在这个Fail的断言一定会失败，并提示没有实现该测试。另外，默认还有两个方法-setUp和-tearDown，正如它们的注释里所述，这两个方法会分别在每个测试开始和结束的时候被调用。我们现在正要开始编写我们的测试，所以先将原来的-testExample删除掉。现在再使用⌘U来进行测试，应该可以顺利通过了（因为我们已经没有任何测试了）。
接下来让我们想想要做什么吧。我们要实现一个简单的栈数据结构，那么当然会有一个类来代表这种数据结构，在这个工程中我打算就叫它VVStack。按照常规，我们可以新建一个Cocoa Touch类，继承NSObject并且开始实现了。但是别忘了，我们现在在TDD，我们需要先写测试！那么首先测试的目标是什么呢？没错，是测试这个VVStack类是否存在，以及是否能够初始化。有了这个目标，我们就可以动手开始编写测试了。在文件开头加上#import "VVStack.h"，然后在VVStackTests.m的@end前面加上如下代码：
|
1 2 3 4 5 6 7 8 |
- (void)testStackExist { XCTAssertNotNil([VVStack class], @"VVStack class should exist."); } - (void)testStackObjectCanBeCreated { VVStack *stack = [VVStack new]; XCTAssertNotNil(stack, @"VVStack object can be created."); } |
嘛，当然是不可能通过测试的，而且甚至连编译都无法完成，因为我们现在根本没有一个叫做VVStack的类。最简单的让测试通过的方法就是在产品代码中添加VVStack类。新建一个Cocoa Touch的Objective-C class，取名VVStack，作为NSObject的子类。注意在添加的时候，应该只将其加入产品的target中：
添加类的时候注意选择合适的target
由于VVStack是NSObject的子类，所以上面的两个断言应该都能通过。这时候再运行测试，成功变绿。接下来我们开始考虑这个类的功能：栈的话肯定需要能够push，并且push后的栈顶元素应该就是刚才所push进去的元素。那么建立一个push方法的测试吧，在刚才添加的代码之下继续写：
|
1 2 3 4 5 6 |
Development，以下简称TDD)是保证代码质量的不二法则，也是先进程序开发的共识。Apple一直致力于在iOS开发中集成更加方便和可用的测试，在Xcode 5中，新的IDE和SDK引入了XCTest来替代原来的SenTestingKit，并且取消了新建工程时的“包括单元测试”的可选项（同样待遇的还有使用ARC的可选项）。新工程将自动包含测试的target，并且相关框架也搭建完毕，可以说测试终于摆脱了iOS开发中“二等公民”的地位，现在已经变得和产品代码一样重要了。我相信每个工程师在完成自己的业务代码的同时，也有最基本的编写和维护相应的测试代码的义务，以保证自己的代码能够正确运行。更进一步，如果能够使用TDD来进行开发，不仅能保证代码运行的正确性，也有助于代码结构的安排和思考，有助于自身的不断提高。我在最开始进行开发时也曾对测试嗤之以鼻，但后来无数的惨痛教训让我明白那么多工程师痴迷于测试或者追求更完美的测试，是有其深刻含义的。如果您之前还没有开始为您的代码编写测试，我强烈建议，从今天开始，从现在开始（也许做不到的话，也请从下一个项目开始），编写测试，或者尝试一下TDD的开发方式。
而Kiwi是一个iOS平台十分好用的行为驱动开发(Behavior Driven Development，以下简称BDD)的测试框架，有着非常漂亮的语法，可以写出结构性强，非常容易读懂的测试。因为国内现在有关Kiwi的介绍比较少，加上在测试这块很能很多工程师们并没有特别留意，水平层次可能相差会很远，因此在这一系列的两篇博文中，我将从头开始先简单地介绍一些TDD的概念和思想，然后从XCTest的最简单的例子开始，过渡到Kiwi的测试世界。在下一篇中我将继续深入介绍一些Kiwi的其他稍高一些的特性，以期更多的开发者能够接触并使用Kiwi这个优秀的测试框架。 什么是TDD，为什么我们要TDD测试驱动开发并不是一个很新鲜的概念了。软件开发工程师们（当然包括你我）最开始学习程序编写时，最喜欢干的事情就是编写一段代码，然后运行观察结果是否正确。如果不对就返回代码检查错误，或者是加入断点或者输出跟踪程序并找出错误，然后再次运行查看输出是否与预想一致。如果输出只是控制台的一个简单的数字或者字符那还好，但是如果输出必须在点击一系列按钮之后才能在屏幕上显示出来的东西呢？难道我们就只能一次一次地等待编译部署，启动程序然后操作UI，一直点到我们需要观察的地方么？这种行为无疑是对美好生命和绚丽青春的巨大浪费。于是有一些已经浪费了无数时间的资深工程师们突然发现，原来我们可以在代码中构建出一个类似的场景，然后在代码中调用我们之前想检查的代码，并将运行的结果与我们的设想结果在程序中进行比较，如果一致，则说明了我们的代码没有问题，是按照预期工作的。比如我们想要实现一个加法函数add，输入两个数字，输出它们相加后的结果。那么我们不妨设想我们真的拥有两个数，比如3和5，根据人人会的十以内的加法知识，我们知道答案是8.于是我们在相加后与预测的8进行比较，如果相等，则说明我们的函数实现至少对于这个例子是没有问题的，因此我们对“这个方法能正确工作”这一命题的信心就增加了。这个例子的伪码如下：
当测试足够全面和具有代表性的时候，我们便可以信心爆棚，拍着胸脯说，这段代码没问题。我们做出某些条件和假设，并以其为条件使用到被测试代码中，并比较预期的结果和实际运行的结果是否相等，这就是软件开发中测试的基本方式。
为什么我们要test 而TDD是一种相对于普通思维的方式来说，比较极端的一种做法。我们一般能想到的是先编写业务代码，也就是上面例子中的 在TDD原则的指导下，我们先编写测试代码。这时因为还没有对应的产品代码，所以测试代码肯定是无法通过的。在大多数测试系统中，我们使用红色来表示错误，因此一个测试的初始状态应该是红色的。接下来我们需要使用最小的代价（最少的代码）来让测试通过。通过的测试将被表示为安全的绿色，于是我们回到了绿色的状态。接下来我们可以添加一些测试例，来验证我们的产品代码的实现是否正确。如果不幸新的测试例让我们回到了红色状态，那我们就可以修改产品代码，使其回到绿色。如此反复直到各种边界和测试都进行完毕，此时我们便可以得到一个具有测试保证，鲁棒性超强的产品代码。在我们之后的开发中，因为你有这些测试的保证，你可以大胆重构这段代码或者与之相关的代码，最后只需要保证项目处于绿灯状态，你就可以保证代码没重构没有出现问题。 简单说来，TDD的基本步骤就是“红→绿→大胆重构”。 使用XCTest来执行TDDXcode 5中已经集成了XCTest的测试框架（之前版本是SenTestingKit和OCUnit），所谓测试框架，就是一组让“将测试集成到工程中”以及“编写和实践测试”变得简单的库。我们之后将通过实现一个栈数据结构的例子，来用XCTest初步实践一下TDD开发。在大家对TDD有一些直观认识之后，再转到Kiwi的介绍。如果您已经在使用XCTest或者其他的测试框架了的话，可以直接跳过本节。 首先我们用Xcode新建一个工程吧，选择模板为空项目，在
新建工程 新建工程后，可以发现在工程中默认已经有一个叫做
Test文件和target 运行测试的快捷键是
失败的初始测试
可以看到， 接下来让我们想想要做什么吧。我们要实现一个简单的栈数据结构，那么当然会有一个类来代表这种数据结构，在这个工程中我打算就叫它
嘛，当然是不可能通过测试的，而且甚至连编译都无法完成，因为我们现在根本没有一个叫做 |
