尋找一個體面的方案來使用原生的Objective-C和Mac技術實現驗收測試環境

Question

背景

我正在尋找一種方法來實現類似於Frank庫用於實現“本機iOS應用程序的自動驗收測試”的方案，但我希望這種方案依賴於原生的iOS / MacOSX技術。 對於以下TLDR ，我們很抱歉，但值得詳細解釋。

1.這里是弗蘭克是如何工作的一個簡短的概述：

它有客戶端和服務器部件。

服務器部分嵌入到我們要運行驗收測試的應用程序中。 Frank教程向我們展示了如何創建應用程序主目標的重復目標，並將Frank HTTP服務器嵌入其中。

客戶端部分 - 主要是運行純文本場景的Cucumber ：每個場景包含應針對app運行的指令（填充文本字段，觸摸按鈕，確保頁面上存在特定元素等...）。 此外，每個場景都會啟動自己的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方法是使用執行軟件重置應用程序的方法編寫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;
});

但是在涉及網絡，異步作業，核心數據，文件操作的應用程序的情況下，很難對先前場景留下的東西進行真正的拆解 。

題

上面描述的問題使我思考是否有可能實現類似於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）從屬於應用程序（MainApp）並且將要求XPC服務生活在我想要避免的應用程序包中。

...我目前的閱讀是分布式對象編程主題 。 在我看來，我會在那里找到答案。 如果沒有人向我提供指南或指示，我會發布一個關於我自己的研究和想法的答案。

...這是我的下一步： iOS上的分布式對象 。

Answer 1

從我的經驗來看， KIF和Jasmine - Cedar到iOS的端口工作得相當好。

然而，我也有很多用葫蘆的好用法，就像弗蘭克一樣，由小黃瓜提供動力。