iOStesting/规格TDD / BDD和集成和验收testing
iPhone上用于行为驱动开发的最佳技术是什么？ 哪些开源示例项目能够充分利用这些技术？ 以下是我find的一些选项：
unit testing
testing::单位样式
- OCUnit / SenTestingKit，如“ iOS开发指南：unit testing应用程序和其他OCUnit参考”中所述 。
- 例子： iPhoneUnitTests ， Three20
- 抓住
- GHUnit
- Google Toolbox for Mac：iPhoneunit testing
RSpec风格
- 猕猴桃 （也有嘲笑和期望）
- 雪松
- 茉莉花与用户界面自动化 ，如在灵巧的“iOS验收testing规范”中所示
验收testing
selenium风格
-
UI自动化（在设备上工作）
- UI自动化仪器指南
- UI自动化参考文档
- Tuneup js – 用于UIAutomation的酷库。
-
将用户界面操作捕获到自动化脚本中
可以使用Cucumber（用JavaScript编写）来驱动UI自动化。 这将是一个伟大的开源项目。 然后，我们可以编写Gherkin来运行UI自动化testing。 现在，我只是写小黄瓜作为评论。
更新： 西葫芦框架似乎混合黄瓜和UI自动化！ 🙂
旧博客文章：
- Alex Vollmer的UI自动化教程
- O'Reilly解答UI自动化教程
- Adi Saxena的UI自动化教程
-
UISpec与UISpecRunner
- UISpec是Google Code上的开源代码 。
- UISpec有全面的文档 。
-
FoneMonkey
黄瓜风格
-
Frank和iCuke （基于Cucumber符合iPhone的谈话 ）
- Frank Google Group比iCuke Google Group有更多的活动。
- Frank在设备和模拟器上运行，而iCuke只在模拟器中运行。
- Frank似乎比iCuke的步骤定义有更全面的步骤定义 。 而且， 弗兰克在他们的维基上也有一个步骤定义纲要 。
- 我build议我们合并iCuke＆Frank （类似于Merb＆Rails合并），因为他们有相同的共同目标：iOS的Cucumber。
-
KIF（保持function）的广场
-
西葫芦框架使用Cucumber语法来编写testing，并使用CoffeeScript作为步骤定义。
附加
- OCMock 嘲笑
- OCHamcrest和/或Expecta的期望
结论
显然，这个问题没有正确的答案，但是我现在select的是：
对于unit testing，我曾经在XCode 4中使用OCUnit / SenTestingKit 。它非常简单和可靠。 但是，我更喜欢BDD在TDD上的语言（ 为什么RSpec比Test :: Unit更好 ？），因为我们的话创造了我们的世界。 所以现在我用ARC和Kiwi代码完成/自动完成使用Kiwi 。 我更喜欢Kiwi，而不是Cedar，因为它是build立在OCUnit的基础之上的，并且带有RSpec风格的matcher和mocks / stubs。 更新：我现在正在调查OCMock，因为目前， 猕猴桃不支持桩免费桥接对象 。
对于验收testing，我使用UI自动化，因为它很棒。 它可以让你logging每个testing用例，使写作testing自动化。 而且，苹果也在开发它，所以它有一个光明的未来。 它也适用于设备和仪器，它允许其他很酷的function，如显示内存泄漏。 不幸的是，使用UI自动化，我不知道如何运行Objective-C代码，但用Frank＆iCuke可以。 所以，我只是用unit testing来testing低层的Objective-C的东西，或者只为TEST构buildconfiguration创buildUIButton ，当它被点击的时候，会运行Objective-C的代码。
你使用哪种解决scheme？
相关问题
- 有没有一个BDD解决scheme，目前适用于iOS4和Xcode4？
- SenTestingKit（与XCode集成）与XCode 4上的GHUnit进行unit testing？
- 使用OCunit在iOS上testingasynchronous代码
- Xcode 4中的SenTestingKit：asynchronoustesting？
- iPhone上的unit testing如何工作？
TL;博士
在Pivotal，我们写了Cedar，因为我们在Ruby项目上使用并热爱Rspec。 雪松并不意味着要取代或与OCUnit竞争; 它意味着将BDD风格的testing带给Objective C，正如Rspec在Ruby中率先使用BDD风格的testing一样，但并没有消除Test :: Unit。 select其中之一很大程度上是风格偏好的问题。
在某些情况下，我们devise了Cedar，以克服OCUnit为我们工作的一些缺点。 具体而言，我们希望能够在testing中使用debugging器，从命令行运行testing并在CI构build中获得testing结果的有用文本输出。 这些东西可能对你来说或多或less有用。
长答案
像Cedar和OCUnit这样的两个testing框架之间的决定归结为两件事情：首选样式和易用性。 我将从风格开始，因为这只是一个意见和偏好的问题。 易用性往往是一套权衡。
风格的考虑超越了你使用的技术或语言。 xUnit风格的unit testing比BDD风格的testing要长得多，但后者已经迅速普及，主要是由于Rspec。
xUnit风格testing的主要优势在于其简单性和广泛的应用（在编写unit testing的开发人员中）; 几乎任何你可以考虑编写代码的语言都有一个xUnit风格的框架。
与xUnit风格相比，BDD风格的框架往往有两个主要区别：如何构buildtesting（或规范），以及编写断言的语法。 对我而言，结构性差异是主要的区别。 xUnittesting是一维的，给定testing类中的所有testing都有一个setUp方法。 然而，我们testing的类不是一维的; 我们经常需要在几个不同的，可能相互冲突的环境中testing行为。 例如，考虑一个简单的ShoppingCart类，使用addItem：方法（为了这个答案，我将使用Objective C语法）。 这种方法的行为可能会有所不同，当购物车是空的相比，当购物车包含其他项目; 如果用户input折扣代码，则可能会有所不同; 如果指定商品不能通过所选送货方式装运，则可能有所不同; 等等。因为这些可能的条件相互交叉，最终的结果是可能的上下文的数量在增加。 在xUnit风格的testing中，这通常会导致许多名称为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中。 这意味着创build一个新的testing目标很简单，而且大多数情况下，testing运行起来“正常”。 另一方面，我们发现在某些情况下（例如在iOS设备上运行），获得OCUnittesting工作几乎是不可能的。 设置雪松规格需要比OCUnittesting更多的工作，因为你已经得到了库和链接自己（在Xcode中从来不是一个简单的任务）。 我们正在努力使设置更容易，任何build议都是值得欢迎的。
-
OCUnit作为构build的一部分运行testing。 这意味着你不需要运行可执行文件来运行你的testing; 如果任何testing失败，你的构build失败。 这使得运行testing的过程变得更简单，testing输出直接进入您的构build输出窗口，这使得它很容易看到。 我们select将Cedar规范构build到您单独运行的可执行文件中，原因如下：
- 我们希望能够使用debugging器。 像运行其他可执行文件一样，您可以运行Cedar规范，所以您可以以相同的方式使用debugging器。
- 我们希望在testing中轻松进行控制台login 您可以在OCUnittesting中使用NSLog（），但输出进入构build窗口，您必须展开构build步骤才能阅读它。
- 我们希望在命令行和Xcode中轻松阅读testing报告。 OCUnit结果很好地显示在Xcode的构build窗口中，但是从命令行构build（或作为CI过程的一部分）会导致testing输出与大量其他构build输出混杂在一起。 使用独立的构build和运行阶段，Cedar将输出分离，以便testing输出很容易find。 默认的Cedartesting运行器复制标准的打印样式“。” 对于每一个通过的规范，“F”为失败的规格等。雪松也有能力使用自定义的记者对象，所以你可以让它输出任何你喜欢的方式，只需一点点的努力。
-
OCUnit是Objective C的官方unit testing框架，并得到了Apple的支持。 苹果基本上拥有无限的资源，所以如果他们想要做的事情就会完成。 毕竟，这是苹果公司正在玩的沙盒。然而，这个硬币的另一面是，苹果每天都会收到一个bajillion的支持请求和bug报告。 他们对于处理这些问题非常好，但是他们可能无法立即处理您所报告的问题，或者根本无法处理。 Cedar比OCUnit更新更新，但是如果您有任何疑问或问题或build议，请发送邮件到Cedar邮件列表（cedar-discuss@googlegroups.com），我们将尽我们所能帮助您。 此外，请随意从Github（github.com/pivotal/cedar）分叉代码，并添加您认为丢失的任何内容。 出于某种原因，我们使testing框架成为开源软件。
-
在iOS设备上运行OCUnittesting可能很困难。 老实说，我还没有尝试过这一段时间，所以它可能变得更容易，但最后一次我尝试了，我根本无法得到任何UIKitfunction工作的OCUnittesting。 当我们写Cedar时，我们确保我们可以在模拟器和设备上testingUIKit相关的代码。
最后，我们写了Cedar进行unit testing，这意味着它不像UISpec这样的项目。 我尝试使用UISpec已经有一段时间了，但是我明白它主要集中在通过编程方式在iOS设备上驱动UI。 自从Apple（当时）即将宣布UIAutomation以来，我们决定不尝试让Cedar支持这些types的规格。
我将不得不把弗兰克扔进验收testing组合。 这是一个相当新的加法，但迄今为止我工作出色。 而且，它实际上正在积极的工作，不像icuke和其他人。
对于testing驱动开发，我喜欢使用GHUnit ，它很容易设置，而且对于debugging也很好。
大名单！
我发现另一个UItestingiOS应用程序的有趣解决scheme。
西葫芦框架
它基于UIAutomation 。 这个框架让你可以在类似黄瓜的风格中编写以屏幕为中心的场景。 这些场景可以在模拟器和控制台的设备上执行（这是CI友好的）。
断言是基于屏幕截图的。 听起来不灵活，但它让你很好的HTML报告，与突出显示的屏幕比较，你可以提供掩码，定义您想要像素精确断言的区域。
每个屏幕都必须在CoffeScript描述，而它自己的工具是用ruby编写的。 这是一种polyglott噩梦，但该工具提供了UIAutomation一个很好的抽象，当画面被描述时，即使质量保证人员是可pipe理的。
我会selectiCuke进行验收testing，Cedar进行unit testing。 UIAutomation是苹果公司朝着正确方向迈出的一步，但这些工具需要更好地支持持续集成; 例如，自动运行仪器的UIAutomationtesting是不可能的。
GHUnit适合unit testing; 对于集成testing，我用UISpec取得了一些成功（github fork在这里： https : //github.com/drync/UISpec ），但期待尝试iCuke，因为它承诺是一个轻量级的设置，你可以使用轨道testing善良，如RSpec和黄瓜。
我目前使用rspec像设置和它的合作伙伴（如上所述） expecta有吨的真棒匹配选项。
我碰巧非常喜欢OCDSpec2，但是我有点偏见，我写了OCDSpec，并为第二个贡献。
即使在iOS上，速度也非常快，部分原因是它是从底层构build而不是置于OCUnit之上。 它也有RSpec / Jasmine语法。
