iOS测试/规格TDD / BDD以及集成和验收测试
iPhone上用于行为驱动开发的最佳技术是什么？ 哪些开源示例项目能够充分利用这些技术？ 以下是我找到的一些选项：
单元测试
测试::单位样式
RSpec样式
验收测试
硒风格
UI自动化（在设备上工作）
将用户界面操作捕获到自动化脚本中
可以使用Cucumber（用JavaScript编写）来驱动UI自动化。 这将是一个伟大的开源项目。 然后，我们可以编写Gherkin来运行UI自动化测试。 现在，我只写小黄瓜作为评论。
更新：西葫芦框架似乎混合黄瓜和UI自动化！ :)
旧博客文章：
UISpec与UISpecRunner
FoneMonkey
黄瓜风格
弗兰克和iCuke（基于Cucumber符合iPhone的谈话）
KIF（保持功能）的广场
西葫芦框架使用Cucumber语法来编写测试，并将CoffeeScript用于步骤定义。
附加
结论
很显然，这个问题没有正确的答案，但是这里是我现在要选择的东西：
对于单元测试，我曾经在XCode 4中使用OCUnit / SenTestingKit。它非常简单实用。 但是，我更喜欢BDD在TDD上的语言（为什么RSpec比Test :: Unit更好？），因为我们的话创造了我们的世界。 所以现在我用ARC和Kiwi代码完成/自动完成来使用Kiwi。 我更喜欢Kiwi而不是Cedar，因为它建立在OCUnit之上，并且配备了RSpec风格的匹配器和模拟/存根。 更新：我现在正在调查OCMock，因为目前Kiwi不支持存取免费桥接对象。
对于验收测试，我使用UI自动化，因为它很棒。 它可以让你记录每个测试用例，使写作测试自动化。 此外，苹果开发它，所以它有一个光明的未来。 它也适用于设备和乐器，它允许其他很酷的功能，如显示内存泄漏。 不幸的是，对于UI自动化，我不知道如何运行Objective-C代码，但是可以使用Frank＆iCuke。 因此，我只是用单元测试来测试低层的Objective-C的东西，或者只为TEST构建配置创建UIButton ，点击后它将运行Objective-C代码。
你使用哪种解决方案？
相关问题
TL;博士
在Pivotal，我们写了Cedar，因为我们在Ruby项目中使用并热爱Rspec。 雪松不是要取代或与OCUnit竞争; 它意味着将BDD风格的测试带给Objective C，就像Rspec在Ruby中率先使用BDD风格的测试一样，但并没有消除Test :: Unit。 选择其中之一很大程度上是风格偏好的问题。
在某些情况下，我们设计了Cedar以克服OCUnit为我们工作的一些缺点。 具体而言，我们希望能够在测试中使用调试器，从命令行和CI构建中运行测试，并获得测试结果的有用文本输出。 这些东西可能对你来说或多或少有用。
长答案
在Cedar和OCUnit这两个测试框架之间做出决定（例如）归结为两点：首选样式和易用性。 我会从风格开始，因为这只是一个意见和偏好问题; 易用性往往是一组折衷。
风格考虑超越您使用的技术或语言。 xUnit风格的单元测试的时间远远超过BDD风格的测试，但后者迅速普及，主要是由于Rspec。
xUnit风格测试的主要优势在于其简单性和广泛的应用（在编写单元测试的开发人员中）; 几乎任何你可以考虑编写代码的语言都有一个xUnit风格的框架。
与xUnit风格相比，BDD风格的框架往往有两个主要区别：您如何构建测试（或规范），以及编写断言的语法。 对我而言，结构性差异是主要的区别。 xUnit测试是一维的，一个setUp方法用于给定测试类中的所有测试。 然而，我们测试的类不是一维的; 我们经常需要在几种不同的，潜在相互冲突的情况下测试行为。 例如，考虑一个简单的ShoppingCart类，带一个addItem：方法（为了这个答案我将使用Objective C语法）。 当购物车为空时，此方法的行为可能会有所不同，与购物车中包含其他物品时相比， 如果用户输入折扣代码，则可能会有所不同; 如果指定商品不能通过所选送货方式装运，则可能会有所不同; 等等。由于这些可能的条件相互交叉，最终可能会出现几何上增加的情况; 在xUnit风格的测试中，这通常会导致许多名称为testAddItemWhenCartIsEmptyAndNoDiscountCodeAndShippingMethodApplies的方法。 BDD风格框架的结构允许您单独组织这些条件，我发现它更容易确保覆盖所有情况，并且更容易查找，更改或添加单个条件。 例如，使用Cedar语法，上面的方法看起来像这样：
describe(@"ShoppingCart", ^{
describe(@"addItem:", ^{
describe(@"when the cart is empty", ^{
describe(@"with no discount code", ^{
describe(@"when the shipping method applies to the item", ^{
it(@"should add the item to the cart", ^{
...
});
it(@"should add the full price of the item to the overall price", ^{
...
});
});
describe(@"when the shipping method does not apply to the item", ^{
...
});
});
describe(@"with a discount code", ^{
...
});
});
describe(@"when the cart contains other items, ^{
...
});
});
});
在某些情况下，您会发现其中的上下文包含相同的断言集，您可以使用共享示例上下文进行干预。
BDD风格的框架和xUnit风格的框架，断言（或“匹配器”）语法之间的第二个主要区别在于简化了规范的风格; 有些人真的喜欢它，有些人却不喜欢它。
这导致了易用性的问题。 在这种情况下，每个框架都有其优缺点：
OCUnit比Cedar更长，并直接集成到Xcode中。 这意味着制作一个新的测试目标很简单，而且大多数情况下，让测试正常运行“只是正常工作”。 另一方面，我们发现在某些情况下（例如在iOS设备上运行），获得OCUnit测试工作几乎是不可能的。 设置Cedar规格需要比OCUnit测试更多的工作，因为你自己已经获得了库和链接（在Xcode中从不是一件简单的任务）。 我们正在努力使设置更容易，任何建议都是值得欢迎的。
OCUnit作为构建的一部分运行测试。 这意味着你不需要运行一个可执行文件来使你的测试运行; 如果任何测试失败，您的构建失败。 这使得运行测试的过程更简单一步，并且测试输出直接进入您的构建输出窗口，从而使其易于查看。 我们选择将Cedar规范构建到您单独运行的可执行文件中，原因如下：
OCUnit是Objective C的官方单元测试框架，并得到Apple的支持。 苹果基本上拥有无限的资源，所以如果他们想要完成某件事情，它就会完成。 毕竟，这是苹果公司正在玩的沙盒。然而，这个硬币的另一面是，苹果公司每天都会收到一个bajillion支持请求和bug报告。 他们在处理所有问题方面表现出色，但他们可能无法处理您立即报告的问题，或根本无法处理。 Cedar比OCUnit更新，更少烘烤，但如果您有任何问题或问题或建议，请发送邮件至Cedar邮件列表（cedar-discuss@googlegroups.com），我们将尽我们所能为您提供帮助。 此外，请随意从Github（github.com/pivotal/cedar）分发代码并添加您认为丢失的任何内容。 出于某种原因，我们使测试框架成为开源代码。
在iOS设备上运行OCUnit测试可能很困难。 老实说，我还没有尝试过一段时间，所以它可能变得更容易了，但是最后一次尝试时，我根本无法获得任何UIKit功能的OCUnit测试。 当我们写Cedar时，我们确保我们可以在模拟器和设备上测试UIKit相关的代码。
最后，我们写了Cedar进行单元测试，这意味着它不像UISpec这样的项目。 从我尝试使用UISpec开始已经有一段时间了，但我明白它主要侧重于以编程方式在iOS设备上驱动UI。 我们特别决定不尝试让Cedar支持这些类型的规格，因为Apple（当时）即将宣布UIAutomation。
我将不得不把弗兰克卷入验收测试组合。 这是一个相当新的加法，但迄今为止我的工作非常出色。 此外，它实际上正在积极的工作，不像icuke和其他人。
对于测试驱动的开发，我喜欢使用GHUnit，它很容易设置，并且对调试起到很好的作用。
链接地址: http://www.djcxy.com/p/19231.html上一篇: iOS Tests/Specs TDD/BDD and Integration & Acceptance Testing