任何类型的集成测试都有一个非常常见的问题是让被测单元进入一个已知状态——为你想要执行的测试设置良好的状态。对于单元测试，通常没有太多状态，唯一的问题是可能模拟与其他类的交互。
另一方面，在测试整个应用程序时，存在各种潜在的持久状态，并使应用程序进入一个干净的状态，或者更棘手的是，进入一个不“干净”的已知状态，而没有任何对应用程序本身的访问权限是有点棘手。
我发现的唯一建议是在应用程序中嵌入任何必要的设置，并使用环境变量之类的东西来触发设置。这当然是可行的，但并不理想。如果可以避免的话，我真的不想在我的最终应用程序中嵌入测试代码和测试数据。
然后是模拟与远程服务的交互。同样，您可以嵌入代码(甚至框架)来执行此操作，并使用环境变量触发它，但我再次不喜欢将 stub 代码嵌入到最终应用程序中的想法。
建议？我找不到太多东西，这让我想知道是否没有人在使用 Xcode UI 测试，或者只是将它用于没有这些问题的非常简单的应用程序。
最佳答案
不幸的是，您提到的两个建议是 Xcode UI 测试在其当前状态下唯一可能的建议。
但是，您可以做一件事来降低在生产应用程序中嵌入测试代码的风险。在 few compiler flags 的帮助下您可以确保特定代码仅在模拟器上运行时构建。
#if (arch(i386) || arch(x86_64)) && os(iOS)
class SeededHTTPClient: HTTPClientProtocol {
/// ... //
}
#endif
我正在构建一些东西，以使这更容易一些。当它准备好使用时，我会回来报告。
关于fixtures - 带有 Xcode UI 测试的应用程序状态/测试装置，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/35078598/