iphone - iOS 测试/规范 TDD/BDD 和集成与验收测试

Question

锁定。这个问题及其答案是locked因为这个问题是题外话，但具有历史意义。它目前不接受新的答案或互动。








在 iPhone 上进行行为驱动开发的最佳技术是什么？哪些开源示例项目展示了这些技术的合理使用？以下是我找到的一些选项:

Unit Testing

Test::Unit风格

OCUnit/SenTestingKit如 iOS Development Guide: Unit Testing Applications 中所述及其他 OCUnit references .

示例:iPhoneUnitTests , Three20

CATCH

GHUnit

Google Toolbox for Mac: iPhone Unit Testing

RSpec风格

Kiwi (也带有 mock 和期望)

Cedar

Jasmine与 UI Automation如dexterous' iOS-Acceptance-Testing specs所示

Acceptance Testing

Selenium风格

UI 自动化(适用于设备)

UI Automation Instruments Guide

UI Automation reference documentation

Tuneup js - 与 UIAutomation 一起使用的酷库。

Capturing User Interface Actions into Automation Scripts

可以使用 Cucumber (written in JavaScript)插入 UI 自动化。这将是一个伟大的开源项目。然后，我们可以写 Gherkin运行 UI 自动化测试。现在，我只会写 Gherkin 作为评论。

更新: Zucchini Framework似乎融合了 Cucumber 和 UI 自动化! :)

旧博客文章:

Alex Vollmer's UI Automation tutorial

O'Reilly Answers UI Automation tutorial

Adi Saxena's UI Automation tutorial

UISpec与 UISpecRunner

UISpec is open source on Google Code .

UISpec has comprehensive documentation .

FoneMonkey

Cucumber风格

Frank和 iCuke (基于 Cucumber meets iPhone talk )

Frank Google Group比 iCuke Google Group 有更多的事件.

Frank 可以在设备和模拟器上运行，而 iCuke 只在模拟器中运行。

Frank 似乎有一套比 iCuke's step definitions 更全面的步骤定义。 .而且，Frank also has a step definition compendium on their wiki .

I proposed that we merge iCuke & Frank (类似于 Merb 和 Rails 的合并方式)，因为它们有相同的共同目标:Cucumber for iOS。

KIF (Keep It Functional)来自 Square

Zucchini Framework使用 Cucumber 语法编写测试，使用 CoffeeScript 定义步骤。

添加

OCMock为 mocking

OCHamcrest和/或 Expecta期待

结论

嗯，显然，这个问题没有正确的答案，但这是我目前选择的:

对于单元测试，我曾经使用 OCUnit/SenTestingKit在 XCode 4 中。它简单而可靠。但是，我更喜欢 BDD 的语言而不是 TDD( Why is RSpec better than Test::Unit？)，因为我们的语言创造了我们的世界。所以现在，我使用 Kiwi with ARC & Kiwi code completion/autocompletion .我更喜欢 Kiwi 而不是 Cedar，因为它建立在 OCUnit 之上，并带有 RSpec 风格的匹配器和模拟/ stub 。更新:我现在正在研究 OCMock 因为，目前， Kiwi doesn't support stubbing toll-free bridged objects .

对于验收测试，我使用 UI 自动化，因为它很棒。它可以让您记录每个测试用例，从而自动编写测试。此外，Apple 开发了它，因此它有一个充满希望的 future 。它也适用于设备和 Instruments，它允许其他很酷的功能，比如显示内存泄漏。不幸的是，使用 UI 自动化，我不知道如何运行 Objective-C 代码，但是使用 Frank & iCuke 可以。因此，我将使用单元测试来测试较低级别的 Objective-C 内容，或者创建 UIButton仅适用于 TEST build configuration ，单击后将运行 Objective-C 代码。

您使用哪些解决方案？

相关问题

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?

Answer 1

tl;博士

在 Pivotal，我们编写了 Cedar，因为我们在 Ruby 项目中使用并喜欢 Rspec。 Cedar 并不是要取代 OCUnit 或与 OCUnit 竞争。它旨在为 Objective C 带来 BDD 风格测试的可能性，就像 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 规范构建到您单独运行的可执行文件中，原因如下:

我们希望能够使用调试器。您可以像运行任何其他可执行文件一样运行 Cedar 规范，因此您可以以相同的方式使用调试器。

我们想要简单的控制台登录测试。您可以在 OCUnit 测试中使用 NSLog()，但输出会进入构建窗口，您必须在其中展开构建步骤才能读取它。

我们想要易于阅读的测试报告，无论是在命令行还是在 Xcode 中。 OCUnit 结果很好地显示在 Xcode 的构建窗口中，但是从命令行构建(或作为 CI 过程的一部分)会导致测试输出与大量其他构建输出混合在一起。通过单独的构建和运行阶段，Cedar 将输出分开，因此测试输出很容易找到。默认的 Cedar 测试运行器复制标准的打印样式“.”。对于每个通过的规范，“F”表示失败的规范等。Cedar 还能够使用自定义报告器对象，因此您可以轻松地以任何您喜欢的方式输出结果。

OCUnit 是 Objective C 的官方单元测试框架，并得到 Apple 的支持。苹果基本上拥有无限的资源，所以如果他们想完成某件事，它就会完成。毕竟，这是我们正在玩的苹果沙盒。然而，硬币的另一面是苹果每天收到大量支持请求和错误报告。他们非常擅长处理所有问题，但他们可能无法立即处理您报告的问题，或者根本无法处理。与 OCUnit 相比，Cedar 更新且不太成熟，但如果您有任何疑问、问题或建议，请向 Cedar 邮件列表 (cedar-discuss@googlegroups.com) 发送消息，我们将竭尽所能为您提供帮助。另外，请随意从 Github (github.com/pivotal/cedar) fork 代码并添加您认为缺少的任何内容。我们将测试框架开源是有原因的。

在 iOS 设备上运行 OCUnit 测试可能很困难。老实说，我已经有一段时间没有尝试过这个了，所以它可能变得更容易了，但是上次我尝试时，我根本无法让任何 UIKit 功能的 OCUnit 测试工作。当我们编写 Cedar 时，我们确保我们可以在模拟器和设备上测试与 UIKit 相关的代码。

最后，我们为单元测试编写了 Cedar，这意味着它无法与 UISpec 等项目相提并论。自从我尝试使用 UISpec 已经有一段时间了，但我理解它主要专注于以编程方式驱动 iOS 设备上的 UI。我们特别决定不尝试让 Cedar 支持这些类型的规范，因为 Apple(当时)即将宣布 UIAutomation。