Xcode iOS单元测试的非常大的数据

时间:2016-04-07 16:38:58

标签: ios xcode unit-testing continuous-integration video-processing

摘要

如何为iOS应用程序的多个大型数据集获得真实的自动单元测试?测试越真实,就越难做;并使用连续集成服务器(唯一可行的测试方法)来解决问题。

但人们这样做。怎么样?

我做了一些平坦的断言。任何可能是不正确的。纠正它们将大大有助于回答我的问题。

项目

这是一款iOS 9应用程序,可分析iOS设备上拍摄的大型视频文件(全分辨率,最大帧速率,10秒典型值)。 (如果重要的话,部分分析将通过OpenCV。)

客户端给了我们一个概念验证(桌面上的Python)和数百个示例文件。称它为8 GB。

我们希望尽可能多地对我们的代码进行单元测试。我的问题是,我们如何针对iOS目标对大型数据集执行自动单元测试?

替代

测试越好,表现越难:

我们将从 OS X应用程序开始,以检查正确性和相对速度。将工具指向任意数量的文件很容易。但是,x86_64具有不同的ABI,OS X是不同的API,而iOS具有Mac无法重现的资源限制。

这会影响正确性和性能测量:您可以继续进行疯狂追逐,以进行适用于桌面但不适用于设备的优化。我们最终将不得不使用Accelerate框架,它不可能在两个平台上执行相同的操作。

移植到iOS后,我们可以使用iOS模拟器,甚至可以为旧目标使用i386(因此也使用32位字)。 (我高兴地发现CGFloat的精度在不同平台之间有所不同。)仍然存在ABI,性能和约束的问题,以及模拟器的“iOS”API经常调用 OS X中的近似等价物。

此外,我不相信模拟设备可以破坏沙箱以读取设备树外的文件。我们必须(我是对的吗?)将测试数据复制到每个模拟设备的存储中,每个开发人员的路径都不同,并且不保证在Xcode版本之间保持稳定。如果解决了这个问题,即使是大型机器仍然会遇到 n × m GB的问题。

(我们可以将所有“存储”文件链接到一个通用副本。可靠性和稳定性问题让我更加高兴。)

最终我们必须在设备上进行测试,因为我们需要未受控制的内存,这是文件大小的一小部分,存储在每年都会发生显着变化的受限制的ARM处理器上。这意味着通过系绳推送视频文件,可能是连续的。用数百个(或几十个)文件挑战设备是不现实的,但是足够的测试套件可能需要8个 - 足够麻烦。

我对于将一系列文件加载到系留设备并将其卸载的简单方法并不乐观。我想我们可能有单独的测试目标,每个测试目标都有两个或三个文件藏在应用程序数据包中,每个文件的测试方案。如果有更清洁的方式,我宁愿不要。

集成

情况变得更糟:测试将是一个漫长而苛刻的过程,乘以每个目标设备。要求我们的任何开发人员主持测试是不现实的(每个人都是BYOD,偶尔也会在场外,我们不要争论它)。将测试文件提交到共享存储库也不现实。 (GitHub断然拒绝。)无论你如何进行测试,都是如此。

这指的是在持续集成服务器上构建和测试。我们不必忍受乏味,但保留测试数据库并将其加载到设备的沙箱(模拟或实际)的实际问题不会消失。

问题

知道这是一个已解决的问题。存在用于移动设备的大型文件项目。开发人员测试它们。

怎么做?

1 个答案:

答案 0 :(得分:0)

今天就碰到这个。幸运的是,我们现在生活在iOS 11以后的时代,并且具有文件提供程序,因此我们只需要将文件手动一次上传到测试设备,然后再将其很好地组织起来即可。