用於 Xcode iOS 單元測試的非常大的數據

Question

總結

如何為 iOS 應用程序的多個大型數據集獲得真實的自動化單元測試？ 測試越現實，就越難做； 使用持續集成服務器（進行測試的唯一實用方法）使問題更加復雜。

但是人們會這樣做。 怎么樣？

我做了一些扁平化的斷言。 任何可能是不正確的。 糾正它們將對回答我的問題大有幫助。

---

項目

這是一個 iOS 9 應用程序，用於分析在 iOS 設備上拍攝的大型視頻文件（全分辨率、最大幀速率、10 秒典型）。 （如果重要的話，部分分析將通過OpenCV 進行。）

客戶給了我們一個概念驗證（桌面上的 Python）和數百個示例文件。 總共稱之為 8 GB。

我們希望針對盡可能多的這些對我們的代碼進行單元測試。 我的問題是，我們如何針對 iOS 目標的大型數據集執行自動化單元測試？

---

替代品

測試越好，執行起來就越困難：

我們將從一個OS X 應用程序開始，以檢查正確性和相對速度。 將工具指向任意數量的文件很容易。 但是， x86_64具有不同的 ABI，OS X 具有不同的 API，iOS 具有 Mac 無法重現的資源限制。

這會影響正確性和性能指標：您可以繼續瘋狂追逐在桌面上而不是在設備上工作的優化。 我們最終將不得不使用 Accelerate 框架，它不可能在兩個平台上執行相同的操作。

---

移植到 iOS 后，我們可以使用 iOS Simulator ，它甚至使用i386 （因此是 32 位字）用於較舊的目標。 （我高興地發現CGFloat的精度因平台而異。）仍然存在 ABI、性能和約束的問題，而且模擬器的“iOS”API 經常調用 OS X 中的近似等價物。

此外，我不相信模擬設備可以打破沙箱以讀取設備樹外的文件。 我們必須（我說得對嗎？）將測試數據復制到每個模擬設備的存儲中，路徑因每個開發人員而異，並且不能保證跨 Xcode 版本穩定。 如果解決了這個問題，即使是大機器也會有n × m GB 的問題。

（我們可以將所有“存儲”文件鏈接到一個公共副本。可靠性和穩定性問題更讓我高興。）

---

最終，我們必須在設備上進行測試，因為我們需要未分頁內存、文件大小的很小倍數的存儲，並且在每年都發生顯着變化的節流 ARM 處理器上進行測試。 這意味着通過系繩推送視頻文件，可能是連續的。 用數百（或數十個）文件來挑戰設備是不現實的，但一個足夠的測試套件可能需要 8 個——這已經足夠麻煩了。

我對有一種直接的方法可以將一系列文件加載和卸載到系留設備中並不樂觀。 我想我們可能有單獨的測試目標，每個測試目標都有兩個或三個文件存放在每個測試方案的應用程序數據包中。 如果有更清潔的方法，我寧願不要。

---

整合

情況變得更糟：測試將是一個漫長而艱巨的過程，每個目標設備都會成倍增加。 要求我們的任何開發人員主持測試是不現實的（每個人都是 BYOD，偶爾會在場外，我們不要爭論）。 將測試文件提交到共享存儲庫也不現實。 （GitHub 斷然拒絕。）無論您如何執行測試，都是如此。

這指向在持續集成服務器上進行構建和測試。 我們不必忍受單調乏味，但保留測試數據庫並將其加載到設備（模擬或實際）的沙箱中的實際問題不會消失。

---

問題

我知道這是一個已解決的問題。 存在用於移動設備的大文件項目。 開發人員測試它們。

它是如何完成的？

Answer 1

今天遇到這個。 幸運的是，我們現在生活在 iOS 11 后時代並且有文件提供程序，所以我們只需要手動將文件上傳到測試設備一次，這只是一個很好的文件名組織。