ios - 寻找一个不错的方案来使用 native Objective-C和Mac技术实现验收测试环境

Question

背景

我正在寻找一种实现类似于Frank library来实现“针对 native iOS应用程序的自动验收测试”的方案的方法，但是我希望该方案依赖于 native iOS/MacOSX技术。很抱歉以下TLDR，但值得详细说明。

1. 以下是Frank的工作原理的简短概述:

它具有客户端和服务器部分。

服务器部分已嵌入到我们要对其进行验收测试的应用程序中。 Frank教程向我们展示了如何创建应用程序主要目标的重复目标，以及如何将Frank HTTP服务器嵌入到该目标。

客户端部分-主要是一个运行纯文本方案的Cucumber:每个方案都包含应针对应用程序运行的指令(填充文本字段，触摸按钮，确保页面上存在特定元素等)。同样，每个方案都将启动自己的应用程序实例，这意味着每次我们进入新方案时都会提供新的状态。

客户端( cucumber 和Ruby-to-Objective-C桥)通过HTTP协议(protocol)与服务器(嵌入到应用程序中的HTTP服务器)进行通信。它使用特殊约定，因此客户端可以告诉服务器应用程序应执行的操作，以便可以执行特定方案。

2. 最近，我发现了Frank Pete Hodgson作者撰写的以下文章:

http://blog.thepete.net/blog/2012/11/18/writing-ios-acceptance-tests-using-kiwi/

他为不喜欢依赖Cucumber和Ruby等外部工具的开发人员提出了一种更简单的编写验收测试的方法。让我引用作者本人:

Before I start, let me be clear that I personally wouldn’t use this approach to writing acceptance tests. I much prefer using a higher-level language like ruby to write these kinds of tests. The test code is way less work and way more expressive, assuming you’re comfortable in ruby. And that’s why I wanted to try this experiment. I’ve spoken to quite a few iOS developers over time who are not comfortable writing tests in ruby. They are more comfortable in Objective-C than anything else, and would like to write their tests in the same language they use for their production code. Fair enough.

这篇博客文章启发了我快速推出自己的原始工具，该工具可以完成Pete在其博客文章NativeAutomation中描述的功能。

确实，就像Pete所描述的那样，仅使用放置在简单OCTests目标中的Kiwi/PublicAutomation设置就可以运行验收测试。我真的很喜欢它，因为:

这只是纯C/Objective-C。构建最初的C帮助程序非常容易，就像Capybara helper:

tapButtonWithTitle, fillTextFieldWithPlaceholder, hasLabelWithTitle and so on...

它不需要外部工具和语言:不需要Cucumber/Ruby或其他任何东西。 NativeAutomation本身仅使用Frank也使用的PublicAutomation。需要PublicAutomation来模拟应用程序屏幕上的用户交互:触摸，填充，手势...

仅通过运行Cocoa Unit Tests捆绑包就可以直接从Xcode运行这些测试。 (尽管命令行构建也很容易)。

问题
Kiwi/PublicAutomation方法存在的问题是，整个测试套件都嵌入到应用程序的捆绑软件中。这意味着在运行每个方案之后，无法重置应用程序以强制其在下一个方案开始执行之前处于全新状态。解决此问题的唯一方法是使用执行应用程序软复位的方法来编写Kiwi's beforeEach钩子(Hook):

+ (void)resetApplication {
[Session invalidateSession];
[LocationManager resetInstance];

[((NavigationController *)[UIApplication sharedApplication].delegate.window.rootViewController) popToRootViewControllerAnimated:NO];

[OHHTTPStubs removeAllStubs];

cleanDatabase();

shouldEventuallyBeTrue(^BOOL{
    return FirstScreen.isCurrentScreen;
});

但是在涉及网络，异步作业，核心数据，文件操作的应用程序中，很难对先前方案剩下的东西执行实际拆卸。

问题

上面描述的问题使我开始思考是否有可能实现类似于Frank方法的更复杂的方法，而第二个应用程序与主应用程序捆绑在一起，并且不依赖Cucumber(Ruby)之类的外部工具。

这是我如何看待它的方式。

除了主应用程序(MainApp)，还有第二个iOS(或Mac OS X)应用程序(AcceptanceTestsRunnerApp)，其中包含整个验收测试套件，并针对主要应用程序捆绑包运行该套件:

在进入每个新方案之前，它会启动新的模拟器实例，并针对当前模拟器的应用实例执行当前方案。

问题是:

我对让我做到这一点的Mac OSX或iOS技术并不了解:我不知道是否甚至可以设置可以控制主程序的Mac OS X/iOS应用程序(AcceptanceTestsRunnerApp)应用程序(MainApp)并对其运行验收测试方案。

对于那些对使用 native Objective-C工具编写iOS应用程序的接受测试的人感到更自在的人，我将不胜感激。

稍后更新

...我确实阅读了一些有关XPC服务的文档，但具有讽刺意味的是，我正在寻找的方案应该与XPC文档所建议的方案完全相反:

理想情况下，我希望我的AcceptanceTestsRunnerApp优于MainApp:通过一些对象代理到MainApp的应用程序委托(delegate)来运行它并对其进行控制(用户交互，关于 View 层次结构的断言)，而XPC服务设置将假定XPC服务(AcceptanceTestsRunnerApp)属于应用程序(MainApp )，并且需要XPC服务存在于应用程序的捆绑包中，我想尽一切办法避免这种情况。

...我目前的读物是Distributed Objects Programming Topics。在我看来，我将在那里找到答案。如果没有人为我提供指导或指示，我将发布有关我自己的研究和思想的答案。

...这是我追求的下一步:Distributed Objects on iOS。

Answer 1

从我的经验来看，KIF和Jasmine的端口-Cedar到iOS的运行效果很好。

但是，从calabash到Frank一样，我也有很多很好的用法。