ma1*_*w28 229 iphone rspec cucumber ios ios-ui-automation
在iPhone上用于行为驱动开发的最佳技术是什么？什么是一些开源示例项目,证明了这些技术的合理使用？以下是我发现的一些选项:
UI自动化(适用于设备)
可以使用Cucumber(用JavaScript编写)来驱动UI自动化.这将是一个伟大的开源项目.然后,我们可以编写Gherkin来运行UI自动化测试.现在,我只会写Gherkin作为评论.
更新:Zucchini框架似乎融合了Cucumber和UI Automation!:)
旧博客帖子:
弗兰克和iCuke(基于黄瓜会见iPhone谈话)
Zucchini Framework使用Cucumber语法编写测试,并使用CoffeeScript进行步骤定义.
嗯,显然,这个问题没有正确的答案,但这是我目前选择的目标:
对于单元测试,我曾经在XCode 4中使用OCUnit/SenTestingKit.它简单而实用.但是,我更喜欢BDD语言而不是TDD(为什么RSpec比Test :: Unit更好？)因为我们的文字创造了我们的世界.所以现在,我使用Kiwi和ARC和Kiwi代码完成/自动完成.我更喜欢Kiwi而非Cedar,因为它建立在OCUnit之上,并配有RSpec风格的匹配器和模拟/存根.更新:我现在正在研究OCMock,因为目前,Kiwi不支持存储免费桥接对象.
对于验收测试,我使用UI自动化,因为它很棒.它允许您记录每个测试用例,自动编写测试.此外,Apple开发它,因此它有一个充满希望的未来.它也适用于设备和Instruments,它允许其他很酷的功能,如显示内存泄漏.不幸的是,使用UI Automation,我不知道如何运行Objective-C代码,但是你可以使用Frank&iCuke.因此,我将使用单元测试来测试较低级别的Objective-C内容,或者UIButton仅为TEST构建配置创建s ,在单击时,将运行Objective-C代码.
你使用哪种解决方案？
Ada*_*gan 53
在Pivotal,我们编写了Cedar,因为我们在Ruby项目中使用和喜欢Rspec.Cedar并不意味着取代OCUnit或与之竞争; 这意味着将BDD风格测试的可能性带到Objective C,正如Rspec在Ruby中开创了BDD风格的测试,但还没有消除Test :: Unit.选择一个或另一个很大程度上取决于风格偏好.
在某些情况下,我们设计了Cedar以克服OCUnit为我们工作的方式中的一些缺点.具体来说,我们希望能够在测试中使用调试器,从命令行和CI构建中运行测试,并获得测试结果的有用文本输出.这些东西可能或多或少对你有用.
在Cedar和OCUnit这两个测试框架之间做出决定(例如)可归结为两件事:首选风格和易用性.我将从风格开始,因为这只是一个观点和偏好的问题; 易用性倾向于一系列权衡.
风格考虑因素超越了您使用的技术或语言.xUnit风格的单元测试比BDD风格测试的时间长得多,但后者迅速普及,主要是由于Rspec.
xUnit风格测试的主要优点是它的简单性和广泛采用(在编写单元测试的开发人员中); 几乎所有你可以考虑编写代码的语言都有一个xUnit风格的框架.
与xUnit-style相比,BDD风格的框架往往有两个主要区别:如何构建测试(或规范),以及编写断言的语法.对我来说,结构差异是主要的区别.xUnit测试是一维的,给定测试类中的所有测试都有一个setUp方法.但是,我们测试的类不是一维的; 我们经常需要在几个不同的,可能相互冲突的环境中测试操作.例如,考虑一个简单的ShoppingCart类,使用addItem:方法(出于本答案的目的,我将使用Objective C语法).与购物车包含其他物品时相比,当购物车为空时,此方法的行为可能不同; 如果用户输入了折扣代码,则可能会有所不同; 如果指定的项目可以'可能会有所不同' 按选定的运输方式运输; 等等.随着这些可能的条件相互交叉,你最终会得到几何数量越来越多的可能背景; 在xUnit样式的测试中,这通常会导致许多方法的名称如testAddItemWhenCartIsEmptyAndNoDiscountCodeAndShippingMethodApplies.BDD风格框架的结构允许您单独组织这些条件,我发现这样可以更容易确保我覆盖所有案例,以及更容易查找,更改或添加个别条件.例如,使用Cedar语法,上面的方法如下所示:在xUnit样式的测试中,这通常会导致许多方法的名称如testAddItemWhenCartIsEmptyAndNoDiscountCodeAndShippingMethodApplies.BDD风格框架的结构允许您单独组织这些条件,我发现这样可以更容易确保我覆盖所有案例,以及更容易查找,更改或添加个别条件.例如,使用Cedar语法,上面的方法如下所示:在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的支持.Apple基本上拥有无限的资源,所以如果他们想要完成任务,它就会完成.而且,毕竟,这是我们正在玩的Apple的沙盒.然而,这个硬币的另一面是Apple每天收到大量的支持请求和错误报告.他们处理这些问题非常好,但他们可能无法处理您立即报告的问题,或者根本无法处理.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.
| 归档时间： |
|
| 查看次数： |
44963 次 |
| 最近记录： |