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进行比较，如果相等，则说明我们的函数实现至少对于这个例子是没有问题的，因此我们对“这个方法能正确工作”这一命题的信心增加了。这个例子的伪码如下：

 

//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!
}

 

　　当测试足够全面和具有代表性的时候，我们便可以信心爆棚，拍着胸脯说，这段代码没问题。我们做出某些条件和假设，并以其为条件使用到被测试代码中，并比较预期的结果和实际运行的结果是否相等，这是软件开发中测试的基本方式。