来自Android / Espresso背景，我仍在为XCUITest和iOS的UI测试而苦苦挣扎。我的问题是关于两个相关但截然不同的问题：
为了解决这些问题，我首先想了解XCode的“单元测试目标”和“ UI测试目标”之间的区别。如果我错了，请纠正我：
XCode的UI测试在完全独立的进程中运行，并且无法跳入被测应用程序的方法。此外，默认情况下，UI测试不会链接到被测应用程序的任何来源。
相反，XCode的单元测试与应用程序源链接在一起。也可以选择执行“ @testable导入”。从理论上讲，这意味着单元测试可以跳转到任意应用程序代码中。但是，单元测试不会针对实际应用程序运行。相反，单元测试针对没有任何UI的精简版iOS SDK进行。我怀疑Android上的Robolectric是类似的东西吗？
现在对于这些约束有不同的解决方法：
将一些选定的源文件添加到UI测试目标。这无法调用应用程序，但至少它可以在应用程序和UI测试之间共享选定的代码。
通过CommandLine.arguments将启动参数从UI测试传递到被测应用。这样可以将动态配置应用于被测应用。但是，这些启动参数需要由应用程序解析和解释，这会导致测试代码对应用程序造成污染。此外，启动参数只是更改被测应用程序行为的一种非交互方式。
这导致了我的结论性问题：
存在哪些替代方法可以使XCUI测试更强大/更动态/更灵活？]
我可以针对整个应用程序源和所有pod依赖项而不是仅选择几个选定的文件来编译和链接UI测试吗？
是否有可能获得Android的测试+ Espresso的强大功能，在这里我们可以对被测应用进行任意状态修改？
来自Android / Espresso背景，我仍在为XCUITest和iOS的UI测试而苦苦挣扎。我的问题是关于两个相关但截然不同的问题：如何根据源代码进行编译和链接...
UI测试不需要链接到应用程序代码，它们旨在模拟用户在您的应用程序内部轻敲。如果您要在这些测试期间跳入应用程序代码，则不再需要测试您的应用程序在现实世界中的功能，而是在测试以任何用户无法操纵的方式操作时的功能。与用户相比，UI测试不需要任何应用程序代码。
作为对@theMikeSwan的回复，我想阐明我对UI测试体系结构的立场。