iOS测试/规格TDD / BDD和集成&验收测试 [英] iOS Tests/Specs TDD/BDD and Integration & Acceptance Testing
问题描述
iPhone上用于行为驱动开发的最佳技术是什么？什么是一些开源示例项目，证明了这些技术的合理使用？以下是我发现的一些选项：
What are the best technologies to use for behavior-driven development on the iPhone? And what are some open source example projects that demonstrate sound use of these technologies? Here are some options I've found:
- iOS开发指南：单元测试应用程序&其他 OCUnit参考资料。
- 示例： iPhoneUnitTests ， Three20
- OCUnit/SenTestingKit as explained in iOS Development Guide: Unit Testing Applications & other OCUnit references.
- Examples: iPhoneUnitTests, Three20
RSpec 样式
RSpec Style
- Kiwi (which also comes with mocking & expectations)
- Cedar
- Jasmine with UI Automation as shown in dexterous' iOS-Acceptance-Testing specs
验收测试
Selenium 样式
Acceptance Testing
Selenium Style
-
UI自动化（适用于设备）
UI Automation (works on device)
- UI Automation Instruments Guide
- UI Automation reference documentation
- Tuneup js - cool library for using with UIAutomation.
Capturing User Interface Actions into Automation Scripts
可以使用 Cucumber（用JavaScript编写）来推动UI自动化。这将是一个伟大的开源项目。然后，我们可以编写 Gherkin 来运行UI自动化测试。现在，我只会写Gherkin作为评论。
It's possible to use Cucumber (written in JavaScript) to drive UI Automation. This would be a great open-source project. Then, we could write Gherkin to run UI Automation testing. For now, I'll just write Gherkin as comments.
更新： Zucchini Framework 似乎融合了Cucumber& UI自动化！ ：）
UPDATE: Zucchini Framework seems to blend Cucumber & UI Automation! :)
旧博客帖子：
- Alex Vollmer's UI Automation tutorial
- O'Reilly Answers UI Automation tutorial
- Adi Saxena's UI Automation tutorial
- UISpec is open source on Google Code.
- UISpec has comprehensive documentation.
黄瓜风格
Cucumber Style
-
Frank 和 iCuke （基于黄瓜会见iPhone谈话）
- Frank Google Group 的活动远远多于 iCuke Google Group 。
- Frank在设备和模拟器上运行，而iCuke只在模拟器中运行。
- Fra nk似乎比 iCuke的步骤有更全面的步骤定义定义的。并且， Frank还在他们的维基上有一个步骤定义纲要。 / li>
- 我提议合并iCuke&弗兰克（类似于Merb& Rails的合并方式）因为他们有相同的共同目标：适用于iOS的黄瓜。
- The Frank Google Group has much more activity than the iCuke Google Group.
- Frank runs on both device and simulator, while iCuke only runs in simulator.
- Frank seems to have a more comprehensive set of step definitions than iCuke's step definitions. And, Frank also has a step definition compendium on their wiki.
- I proposed that we merge iCuke & Frank (similar to how Merb & Rails merged) since they have the same common goal: Cucumber for iOS.
Zucchini Framework 使用Cucumber语法编写测试，并使用CoffeeScript进行步骤定义。
Zucchini Framework uses Cucumber syntax for writing tests and uses CoffeeScript for step definitions.
增加
- 嘲笑的noreferrer> OCMock
- OCHamcrest 和/或 Expecta 的期望
- OCMock for mocking
- OCHamcrest and/or Expecta for expectations
- 是否有适用于iOS4和Xcode4的BDD解决方案？
- SenTestingKit（与XCode集成）与针对XCode 4的GHUnit进行单元测试？
- 测试异步鳕鱼e在iOS上使用OCunit
- Xcode 4中的SenTestingKit：异步测试？
- iPhone上的单元测试如何工作？
- Is there a BDD solution that presently works well with iOS4 and Xcode4?
- SenTestingKit (integrated with XCode) versus GHUnit on XCode 4 for Unit Testing?
- Testing asynchronous code on iOS with OCunit
- SenTestingKit in Xcode 4: Asynchronous testing?
- How does unit testing on the iPhone work?
Additions
嗯，显然，这个问题没有正确答案，但是这就是我目前选择的目标：
Well, obviously, there's no right answer to this question, but here's what I'm choosing to go with currently:
对于单元测试，我曾经使用 OCUnit / SenTestingKit 。这很简单&固体。但是，我更喜欢BDD而不是TDD的语言（为什么是RSpec比Test :: Unit 好吗？）因为我们的话创造了我们的世界。现在，我使用 Kiwi with ARC & 新西兰代码完成/自动完成。我更喜欢Kiwi而非Cedar，因为它建立在OCUnit之上，并配有RSpec风格的匹配器和放大器。嘲笑/存根。更新：我现在正在调查OCMock，因为目前 Kiwi不支持免费存根桥接对象。
For unit testing, I used to use OCUnit/SenTestingKit in XCode 4. It's simple & solid. But, I prefer the language of BDD over TDD (Why is RSpec better than Test::Unit?) because our words create our world. So now, I use Kiwi with ARC & Kiwi code completion/autocompletion. I prefer Kiwi over Cedar because it's built on top of OCUnit and comes with RSpec-style matchers & mocks/stubs. UPDATE: I'm now looking into OCMock because, currently, Kiwi doesn't support stubbing toll-free bridged objects.
对于验收测试，我使用UI自动化，因为它很棒。它允许您记录每个测试用例，自动编写测试。此外，Apple开发它，因此它有一个充满希望的未来。它也适用于设备和Instruments，它允许其他很酷的功能，如显示内存泄漏。不幸的是，使用UI自动化，我不知道如何运行Objective-C代码，但使用Frank& iCuke你可以。因此，我将仅使用单元测试来测试较低级别的Objective-C内容，或者仅为 UIButton 。 com / questions / 6748087 / xcode-test-vs-debug-preprocessor-macros / 6763597> TEST 构建配置，单击后将运行Objective-C代码。
For acceptance testing, I use UI Automation because it's awesome. It lets you record each test case, making writing tests automatic. Also, Apple develops it, and so it has a promising future. It also works on the device and from Instruments, which allows for other cool features, like showing memory leaks. Unfortunately, with UI Automation, I don't know how to run Objective-C code, but with Frank & iCuke you can. So, I'll just test the lower-level Objective-C stuff with unit tests, or create UIButtons only for the TEST build configuration, which when clicked, will run Objective-C code.
您使用哪种解决方案？
推荐答案
tl; dr
在Pivotal，我们编写了Cedar，因为我们在Ruby项目中使用和喜欢Rspec。 Cedar并不意味着要替换OCUnit或与之竞争;这意味着将BDD风格测试的可能性带到Objective C，正如Rspec在Ruby中开创了BDD风格的测试，但还没有消除Test :: Unit。选择其中一个很大程度上取决于风格偏好。
tl;dr
At Pivotal we wrote Cedar because we use and love Rspec on our Ruby projects. Cedar isn't meant to replace or compete with OCUnit; it's meant to bring the possibility of BDD-style testing to Objective C, just as Rspec pioneered BDD-style testing in Ruby, but hasn't eliminated Test::Unit. Choosing one or the other is largely a matter of style preferences.
在某些情况下，我们设计了Cedar以克服OCUnit为我们工作的方式中的一些缺点。具体来说，我们希望能够在测试中使用调试器，从命令行和CI构建中运行测试，并获得测试结果的有用文本输出。这些对你来说可能或多或少有用。
In some cases we designed Cedar to overcome some shortcomings in the way OCUnit works for us. Specifically, we wanted to be able to use the debugger in tests, to run tests from the command line and in CI builds, and get useful text output of test results. These things may be more or less useful to you.
决定两个测试框架如Cedar和OCUnit（例如）归结为两件事：首选风格和易用性。我将从风格开始，因为这只是一个观点和偏好的问题;易用性往往是一组权衡。
Deciding between two testing frameworks like Cedar and OCUnit (for example) comes down to two things: preferred style, and ease of use. I'll start with the style, because that's simply a matter of opinion and preference; ease of use tends to be a set of tradeoffs.
样式考虑因素超越了您使用的技术或语言。 xUnit风格的单元测试比BDD风格的测试要长得多，但后者很快就流行起来，主要是由于Rspec。
Style considerations transcend what technology or language you use. xUnit-style unit testing has been around for far longer than BDD-style testing, but the latter has rapidly gained in popularity, largely due to Rspec.
xUnit风格测试的主要优点是它的简单性和广泛采用（在编写单元测试的开发人员中）;几乎所有你可以考虑编写代码的语言都有一个xUnit风格的框架。
The primary advantage of xUnit-style testing is its simplicity, and wide adoption (amongst developers who write unit tests); nearly any language you could consider writing code in has an xUnit-style framework available.
与xUnit-style相比，BDD风格的框架往往有两个主要区别：如何您构建测试（或规范），以及编写断言的语法。对我来说，结构差异是主要的区别。 xUnit测试是一维的，给定测试类中的所有测试都有一个setUp方法。但是，我们测试的类不是一维的;我们经常需要在几个不同的，可能相互冲突的上下文中测试操作。例如，考虑一个简单的ShoppingCart类，使用addItem：方法（出于本答案的目的，我将使用Objective C语法）。与购物车包含其他物品时相比，当购物车为空时，此方法的行为可能会有所不同;如果用户输入了折扣代码，则可能会有所不同;如果指定的商品无法通过所选的送货方式发货，则可能会有所不同;当这些可能的条件相互交叉时，你最终会得到几何上可能的上下文数量;在xUnit样式的测试中，这通常会导致很多方法的名称如testAddItemWhenCartIsEmptyAndNoDiscountCodeAndShippingMethodApplies。 BDD风格框架的结构允许您单独组织这些条件，我发现这样可以更容易确保我覆盖所有案例，以及更容易查找，更改或添加个别条件。例如，使用Cedar语法，上面的方法如下所示：
BDD-style frameworks tend to have two main differences when compared to xUnit-style: how you structure the test (or specs), and the syntax for writing your assertions. For me, the structural difference is the main differentiator. xUnit tests are one-dimensional, with one setUp method for all tests in a given test class. The classes that we test, however, aren't one-dimensional; we often need to test actions in several different, potentially conflicting, contexts. For example, consider a simple ShoppingCart class, with an addItem: method (for the purposes of this answer I'll use Objective C syntax). The behavior of this method may differ when the cart is empty compared to when the cart contains other items; it may differ if the user has entered a discount code; it may differ if the specified item can't be shipped by the selected shipping method; etc. As these possible conditions intersect with one another you end up with a geometrically increasing number of possible contexts; in xUnit-style testing this often leads to a lot of methods with names like testAddItemWhenCartIsEmptyAndNoDiscountCodeAndShippingMethodApplies. The structure of BDD-style frameworks allows you to organize these conditions individually, which I find makes it easier to make sure I cover all cases, as well as easier to find, change, or add individual conditions. As an example, using Cedar syntax, the method above would look like this:
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, ^{
...
});
});
});
在某些情况下，您会发现包含相同断言集的上下文，您可以将其干掉使用共享示例上下文。
In some cases you'll find contexts in that contain the same sets of assertions, which you can DRY up using shared example contexts.
BDD样式框架和xUnit样式框架之间的第二个主要区别，断言（或匹配器）语法，简单地使得样式规格有点好;有些人非常喜欢它，有些则不喜欢。
The second main difference between BDD-style frameworks and xUnit-style frameworks, assertion (or "matcher") syntax, simply makes the style of the specs somewhat nicer; some people really like it, others don't.
这导致了易用性的问题。在这种情况下，每个框架都有其优点和缺点：
That leads to the question of ease of use. In this case, each framework has its pros and cons:
-
OCUnit比Cedar长得多，并且直接集成进入Xcode。这意味着制作一个新的测试目标很简单，而且大多数时候，让测试运行起来并正常运行。另一方面，我们发现在某些情况下，例如在iOS设备上运行，让OCUnit测试工作几乎是不可能的。设置Cedar规范比OCUnit测试需要更多的工作，因为你已经获得了库并自己链接它（在Xcode中从来不是一个简单的任务）。我们正在努力使设置更容易，任何建议都非常受欢迎。
OCUnit has been around much longer than Cedar, and is integrated directly into Xcode. This means it's simple to make a new test target, and, most of the time, getting tests up and running "just works." On the other hand, we found that in some cases, such as running on an iOS device, getting OCUnit tests to work was nigh impossible. Setting up Cedar specs takes some more work than OCUnit tests, since you have get the library and link against it yourself (never a trivial task in Xcode). We're working on making setup easier, and any suggestions are more than welcome.
OCUnit作为构建的一部分运行测试。这意味着您无需运行可执行文件即可运行测试;如果任何测试失败，您的构建将失败。这使得运行测试的过程更加简单，测试输出直接进入构建输出窗口，这使得它很容易看到。我们选择将Cedar规范构建为可执行文件，由于以下几个原因而单独运行：
OCUnit runs tests as part of the build. This means you don't need to run an executable to make your tests run; if any tests fail, your build fails. This makes the process of running tests one step simpler, and test output goes directly into your build output window which makes it easy to see. We chose to have Cedar specs build into an executable which you run separately for a few reasons:
- 我们希望能够使用调试器。您运行Cedar规范就像运行任何其他可执行文件一样，因此您可以以相同的方式使用调试器。
- 我们希望在测试中轻松进行控制台记录。您可以在OCUnit测试中使用NSLog（），但输出会进入构建窗口，您必须展开构建步骤才能读取它。
- 我们希望在命令行和Xcode中都能轻松阅读测试报告。 OCUnit结果很好地出现在Xcode的构建窗口中，但是从命令行构建（或作为CI过程的一部分）会导致测试输出与许多其他构建输出混合在一起。通过单独的构建和运行阶段，Cedar将输出分开，以便轻松找到测试输出。默认的Cedar测试运行器复制标准打印样式。对于每个传递规范，F表示失败的规格等.Cedar还能够使用自定义报告对象，因此您可以轻松地以任意方式输出结果。
OCUnit是Objective C的官方单元测试框架，Apple支持。 Apple基本上拥有无限的资源，所以如果他们想要完成任务，它就会完成。而且，毕竟，这是我们正在玩的Apple的沙箱。然而，这个硬币的另一面是Apple每天收到大量支持请求和错误报告的订单。他们处理这些问题非常好，但他们可能无法处理您立即报告的问题，或者根本无法处理。 Cedar比OCUnit更新，更少烘焙，但如果您有任何问题或建议，请发送信息至Cedar邮件列表（cedar-discuss@googlegroups.com），我们将尽我们所能帮助您。此外，随意从Github（github.com/pivotal/cedar）分叉代码并添加您认为缺少的任何内容。我们将测试框架开源是有原因的。
OCUnit is the official unit testing framework for Objective C, and is supported by Apple. Apple has basically limitless resources, so if they want something done it will get done. And, after all, this is Apple's sandbox we're playing in. The flip side of that coin, however, is that Apple receives on the order of a bajillion support requests and bug reports each day. They're remarkably good about handling them all, but they may not be able to handle issues you report immediately, or at all. Cedar is much newer and less baked than OCUnit, but if you have questions or problems or suggestions send a message to the Cedar mailing list (cedar-discuss@googlegroups.com) and we'll do what we can to help you out. Also, feel free to fork the code from Github (github.com/pivotal/cedar) and add whatever you think is missing. We make our testing frameworks open source for a reason.
在iOS设备上运行OCUnit测试可能很困难。老实说，我已经有一段时间没试过了，所以它可能变得更容易了，但是我最后一次尝试时根本无法让任何UIKit功能的OCUnit测试工作。当我们编写Cedar时，我们确保可以在模拟器和设备上测试与UIKit相关的代码。
Running OCUnit tests on iOS devices can be difficult. Honestly, I haven't tried this for quite some time, so it may have gotten easier, but the last time I tried I simply couldn't get OCUnit tests for any UIKit functionality to work. When we wrote Cedar we made sure that we could test UIKit-dependent code both on the simulator and on devices.
最后，我们为单元测试编写了Cedar，这意味着它与UISpec等项目并不具有可比性。自从我尝试使用UISpec以来已经有一段时间了，但我知道它主要集中在以iOS设备编程方式驱动UI。我们特别决定不让Cedar支持这些类型的规格，因为Apple（当时）即将宣布UIAutomation。
Finally, we wrote Cedar for unit testing, which means it's not really comparable with projects like UISpec. It's been quite a while since I tried using UISpec, but I understood it to be focused primarily on programmatically driving the UI on an iOS device. We specifically decided not to try to have Cedar support these types of specs, since Apple was (at the time) about to announce UIAutomation.
这篇关于iOS测试/规格TDD / BDD和集成&验收测试的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
