寻找一个体面的方案来使用原生的Objective-C和Mac技术实现验收测试环境

Sta*_*ich 6 macos automation ios frank

背景

我正在寻找一种方法来实现类似于Frank库用于实现"本机iOS应用程序的自动验收测试"的方案,但我希望这种方案依赖于原生的iOS/MacOSX技术.对不起,TLDR但它值得详细解释.

1.这里是弗兰克是如何工作的一个简短的概述:

它有客户端和服务器部件.

服务器部分嵌入到我们要运行验收测试的应用程序中.Frank教程向我们展示了如何创建应用程序主目标的重复目标,并将Frank HTTP服务器嵌入其中.

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

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

2.最近,我发现弗兰克·皮特霍奇森的作者所写的以下文章:

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

他建议更简单的方法为不喜欢依赖Cucumber和Ruby等外部工具的开发人员编写验收测试.让我自己引用作者:

在我开始之前,让我明确一点,我个人不会使用这种方法来编写验收测试.我更喜欢使用像ruby这样的高级语言来编写这些类型的测试.假设你对红宝石感到满意,那么测试代码的工作量就会减少,表达方式也会更具表现力.这就是我想尝试这个实验的原因.随着时间的推移,我和很多iOS开发人员谈过,他们不喜欢用红宝石编写测试.他们在Objective-C中比其他任何东西都更舒服,并且希望用他们用于生产代码的相同语言编写测试.很公平.

这篇博客文章激励我快速推出自己非常原始和原始的工具,这正是Pete在他的博客文章中所描述的:NativeAutomation.

实际上,就像Pete所描述的那样,可以通过使用放置在简单OCTests目标中的Kiwi/PublicAutomation设置来运行验收测试.我真的很喜欢它,因为:

  • 它只是纯粹的C/Objective-C.构建初始的C帮助程序很容易,看起来像Capybara帮助程序:

tapButtonWithTitle,fillTextFieldWithPlaceholder,hasLabelWithTitle等等......

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

  • 通过运行Cocoa Unit Tests包从Xcode运行这些测试非常方便.(虽然命令行构建也很容易).

问题

问题的Kiwi/PublicAutomation方法是将整个测试套件嵌入到应用程序包中.这意味着在每个场景运行后,在下一个场景开始执行之前,无法重置应用程序以强制它处于新鲜状态.解决此问题的唯一方法是Kiwi's beforeEach使用执行应用程序的软重置的方法编写钩子,如:

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

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

[OHHTTPStubs removeAllStubs];

cleanDatabase();

shouldEventuallyBeTrue(^BOOL{
    return FirstScreen.isCurrentScreen;
});
Run Code Online (Sandbox Code Playgroud)

但是在涉及网络,异步作业,核心数据,文件操作的应用程序的情况下,很难对先前场景留下的东西进行真正的拆解.

上面描述的问题使我思考是否有可能实现类似于Frank方法的更复杂的方法,第二个应用程序与主应用程序的捆绑包不同,并且不依赖于像Cucumber(Ruby)这样的外部工具.

以下是我如何看待它的完成方式.

除了主应用程序(MainApp)之外,还有第二个iOS(或Mac OS X)应用程序(AcceptanceTestsRunnerApp),它包含整个验收测试套件,并针对主应用程序包运行此套件:

它会在进入每个新场景之前启动新的模拟器实例,并针对当前模拟器的应用程序实例执行当前场景.


问题是:

我不太了解允许我这样做的Mac OSX或iOS技术:我不知道是否甚至可以设置可以控制主应用程序的Mac OS X/iOS应用程序(AcceptanceTestsRunnerApp) (MainApp)并针对它运行验收测试场景.

对于那些对使用原生Objective-C工具编写iOS应用程序验收测试的人感觉更舒服的人,我会感激不尽.


更新后来

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

理想情况下,我希望我的AcceptanceTestsRunnerApp在MainApp上占主导地位:运行它并通过代理MainApp应用程序委托的一些对象来控制它(用户交互,关于视图层次结构的断言),而XPC服务设置将假定XPC服务(AcceptanceTestsRunnerApp)从属于app(MainApp)并且将要求XPC服务生活在我想要避免的应用程序包中.

...我目前的阅读是分布式对象编程主题.在我看来,我会在那里找到答案.如果没有人向我提供指南或指示,我会发布一个关于我自己的研究和想法的答案.

...这是我的下一步:iOS上的分布式对象.

Jos*_*yer 0

根据我的经验, KIF和 Jasmine - Cedar到 iOS 的移植效果相当好。

然而,我也对calabash有了很多很好的使用,它像 Frank 一样,由 gherkin 提供支持。