logo标签列表

iOS测试/规范 TDD/BDD以及集成与验收测试

iphoneiosrspeccucumberios-ui-automation
229

什么是在iPhone上使用行为驱动开发的最佳技术？有哪些开源示例项目演示了这些技术的良好应用？以下是我找到的一些选项：

单元测试

Test::Unit 风格

  1. OCUnit/SenTestingKit，如iOS开发指南：应用程序单元测试以及其他OCUnit参考资料所解释的那样。
  2. CATCH
  3. GHUnit
  4. Google Toolbox for Mac: iPhone Unit Testing

RSpec 风格

  1. Kiwi（还带有模拟和期望）
  2. Cedar
  3. Jasmine与dexterous' iOS-Acceptance-Testing specs中展示的UI Automation

验收测试

Selenium 风格

  1. UI Automation（适用于设备）

    更新：Zucchini Framework似乎将Cucumber和UI自动化混合在一起！:)

    旧博客文章：

  2. UISpec与UISpecRunner

  3. FoneMonkey

黄瓜风格

  1. Frank和iCuke（基于Cucumber meets iPhone talk）

  2. Square的KIF（Keep It Functional）

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

新增内容

结论

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

对于单元测试，我过去在XCode 4中使用OCUnit/SenTestingKit。它简单而稳定。但是，我更喜欢BDD的语言而不是TDD(为什么RSpec比Test::Unit更好？)，因为我们的言语创造了我们的世界。所以现在，我使用带有ARC的Kiwi和Kiwi代码完成/自动完成。我更喜欢Kiwi而不是Cedar，因为它构建在OCUnit之上，并带有RSpec风格的匹配器和mocks/stubs。更新：我现在正在研究OCMock，因为目前Kiwi不支持存根toll-free bridged对象。

对于验收测试，我使用UI自动化，因为它非常棒。它可以记录每个测试用例，使编写测试自动化。此外，苹果开发了它，所以它有一个光明的未来。它还可以在设备和仪器上工作，这允许其他酷炫的功能，比如显示内存泄漏。不幸的是，使用UI自动化，我不知道如何运行Objective-C代码，但是使用Frank & iCuke，您可以。因此，我将只使用单元测试来测试更低级别的Objective-C内容，或者仅为TEST构建配置创建UIButton，当点击时，将运行Objective-C代码。
您使用哪些解决方案？
相关问题
1
我知道至少几个月前 Pivotal Labs 在使用 Cedar（嗯，鉴于它在他们的 GitHub 账户上，这显而易见）。有像他们这样的公司支持，那将是我的选择。 - Jed Schneider
1
这是一个很好的观点。但另一方面，苹果公司会建议使用他们的单元测试框架，而不是Cedar，对吧？那么，这就是Pivotal和苹果之间的选择。该选哪个呢？ - ma11hew28
2
我写了一篇帖子，比较了Frank、KIF和UIAutomation三种自动化iOS测试工具，可能会对本帖读者感兴趣。http://sgleadow.github.com/blog/2011/10/26/which-automated-ios-testing-tool-to-use/ - Stew
8个回答
53

tl;dr

Cedar is a BDD-style testing framework for Objective C, designed to bring BDD-style testing to the language without replacing OCUnit. Cedar offers features like debugging in tests, running tests from the command line, and useful text output of test results.

Long answer

Choosing between testing frameworks like Cedar and OCUnit depends on preferred style and ease of use. BDD-style frameworks like Cedar differ from xUnit-style in how tests are structured and how assertions are written. Cedar's structure allows for easier organization of complex conditions and makes it easier to find, change or add individual conditions. 

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, ^{
            ...
        });
    });
});
在某些情况下，你会发现包含相同断言集合的上下文，可以使用共享样例上下文来DRY up它们。
BDD风格框架和xUnit风格框架之间的第二个主要区别是断言（或“匹配器”）语法，只是使规范的风格更好一些；有些人真的很喜欢它，而有些人则不喜欢。
这就引出了易用性的问题。在这种情况下，每个框架都有其优点和缺点：
- OCUnit存在的时间比Cedar长得多，并且直接集成到Xcode中。这意味着创建一个新的测试目标很简单，大部分情况下，让测试运行起来“只是工作”。另一方面，我们发现在某些情况下，例如在iOS设备上运行，让OCUnit测试工作几乎是不可能的。设置Cedar规范需要比OCUnit测试更多的工作，因为您必须自己获取库并链接它（在Xcode中从来不是一项微不足道的任务）。我们正在努力使设置更加容易，欢迎任何建议。 - OCUnit将测试作为构建的一部分运行。这意味着您不需要运行可执行文件来使测试运行；如果有任何测试失败，则构建失败。这使运行测试的过程更加简单，测试输出直接进入您的构建输出窗口，因此很容易查看。我们选择将Cedar规范构建为可执行文件，需要单独运行几个原因： - 我们想要能够使用调试器。您可以像运行任何其他可执行文件一样运行Cedar规范，因此可以以相同的方式使用调试器。 - 我们想要在测试中进行轻松的控制台日志记录。您可以在OCUnit测试中使用NSLog()，但输出会进入构建窗口，您必须展开构建步骤才能阅读它。 - 我们希望易于阅读的测试报告，无论是在命令行还是在Xcode中。OCUnit结果在Xcode的构建窗口中显示得很好，但是从命令行（或作为CI过程的一部分）进行构建会导致测试输出与大量其他构建输出交织在一起。通过单独的构建和运行阶段，Cedar将输出分开，使得测试输出易于找到。默认的Cedar测试运行程序复制每个通过spec打印“.”，每个失败的spec打印“F”等的标准样式。Cedar还具有使用自定义报表对象的功能，因此您可以以任何方式输出结果，只需付出少许的努力。

OCUnit是Objective C的官方单元测试框架，由Apple支持。由于Apple拥有无限的资源，所以只要他们想完成某件事情，就一定会完成。毕竟，我们正在玩的是Apple的沙盒游戏。然而，反过来，苹果每天收到大约10亿个支持请求和错误报告。他们非常善于处理这些问题，但可能无法立即或根本解决您报告的问题。Cedar比OCUnit新得多，也没那么成熟，但如果您有问题、建议或者遇到问题，请发送消息到Cedar邮件列表（cedar-discuss@googlegroups.com），我们将尽力帮助您。此外，随意从Github（github.com/pivotal/cedar）派生代码并添加您认为缺少的任何内容。我们将我们的测试框架开源出来有原因。

在iOS设备上运行OCUnit测试可能会很困难。老实说，我已经有一段时间没有尝试过了，所以现在可能会更容易，但上一次尝试的时候，我根本无法让OCUnit测试UIKit功能。当我们编写Cedar时，我们确保可以在模拟器和设备上测试依赖于UIKit的代码。

最后，我们为单元测试编写了Cedar，这意味着它与像UISpec这样的项目并不是真正可比的。我尝试使用UISpec已经有一段时间了，但我理解它主要集中在通过编程方式驱动iOS设备上的UI。我们特别决定不尝试支持这些类型的规范，因为当时Apple即将宣布UIAutomation。

感谢您详细的回复。我将阅读RSpec书籍并尝试Ceder。我将UISpec移至Selenium部分，并在那里添加了UIAutomation。我正在阅读您有关UIAutomation的博客文章。Frank看起来实际上更简单、更易读，而且文档也更好，所以我考虑从那里开始。我只希望它和UIAutomation一样强大。您说UIAutomation可以测试生命周期问题。我想知道iCuke是否也可以... - ma11hew28
8

我将不得不把Frank加入验收测试中。这是一个相当新的添加，但到目前为止对我来说效果非常好。此外，与icuke和其他工具不同，它实际上正在积极开发。

5

对于测试驱动开发，我喜欢使用GHUnit，它非常容易设置，并且在调试方面也非常出色。

谢谢。我看到了那个，但忘记提到它了。 - ma11hew28
为GHUnit加1。我经常与OCMock一起使用它。设置、扩展和工作非常可靠，简单易行。 - drekka
4

好的列表!

我找到了另一个有趣的解决方案，用于UI测试iOS应用程序。

Zucchini Framework

它基于UIAutomation。该框架允许您以类似于Cucumber的方式编写以屏幕为中心的场景。这些场景可以从控制台在模拟器和设备上执行（适合CI）。

断言是基于截图的。听起来不太灵活，但它会给您一个漂亮的HTML报告，带有突出显示的屏幕比较，并且您可以提供定义要具有像素精确断言的区域的掩码。

每个屏幕都必须用CoffeScript描述，工具本身是用ruby编写的。这有点多语言噩梦，但该工具为UIAutomation提供了良好的抽象，一旦描述了屏幕，即使对于QA人员也是可管理的。

太好了！谢谢。我已经将这个添加到上面的问题中了。 - ma11hew28
2
我会选择iCuke进行验收测试，选择Cedar进行单元测试。UIAutomation是Apple朝着正确方向迈出的一步，但该工具需要更好地支持持续集成；例如，目前无法自动使用Instruments运行UIAutomation测试。
1

GHUnit适用于单元测试；对于集成测试，我曾经使用过UISpec并取得了一些成功（github分支在这里：https://github.com/drync/UISpec），但是我期待尝试iCuke，因为它承诺是一个轻量级的设置，并且您可以使用Rails测试工具，如RSpec和Cucumber。

1
我目前使用specta进行类似rspec的设置，它的合作伙伴（如上所述）是expecta，具有大量令人惊叹的匹配选项。
0

我碰巧非常喜欢OCDSpec2，但是我有偏见，因为我编写了OCDSpec并为第二版做出了贡献。

它非常快速，即使在iOS上也是如此，部分原因是因为它是从头开始构建的，而不是放在OCUnit之上。 它还具有RSpec / Jasmine语法。

https://github.com/ericmeyer/ocdspec2

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接