是否可以将 Espresso 与 Mockito 搭配使用？我有一个应用程序，我们从身份验证中调用 API 2 次，我们正在尝试将 Espresso 与 Mockito 一起使用，以模拟接近 UI 的几种方法。项目中没有 dagger 或任何其他依赖注入工具，也没有单元测试。
我已经与 Espresso 合作过另一个，我们用 WebMockServer 模拟了 API。该应用程序有很多网络，这很棒，我们能够测试一切。现在，我不会嘲笑任何事情。
【问题讨论】：
标签： java android kotlin mockito android-espresso
Espresso 是一个 UI 测试框架，Mockito 是一个模拟框架。他们一起工作得很好。
我认为您提出的问题更多取决于the difference between white box testing and black box testing。在使用应用程序 UI 时，Espresso 非常有能力进行白盒测试和黑盒测试；您可以针对应用程序编写 Espresso 测试，而无需编辑或访问其内部（黑框），或者您可以与 UI 交互，同时了解内部并重新配置它们以进行测试（白框）。相比之下，Mockito 提供类和接口的模拟实现，因此为了让您使用 Mockito 编写的实现进行测试，您需要重新配置您的应用程序以像在白盒中一样使用它测试。
您已将您的应用程序描述为缺少依赖项注入和单元测试，这表明您的组件在编写时可能没有考虑到可配置性或测试接缝。您将需要这样的接缝，以允许将您的实现替换为 WebMockServer 或 Mockito 提供的实现。
对于一个快速而简单的解决方案测试接缝，您可以简单地在您尝试测试的 Activity、Fragment 或 View 上创建一个公共字段，从而允许您从测试中替换该实现。您需要更改代码以接受该字段中的 test-double 值，而不是创建自己的实现。对于 Activity 或 Fragment，您可以使用自己的 ActivityScenario.ActivityAction 实现进入现场，然后执行 onActivity as in the sample；对于视图，您可以类似地编写ViewAction，然后以相同的方式执行onView。用您自己的实现替换该字段，您就可以开始了。
当然，这种方法也存在隐患：从技术角度来看，Activity 可以随意重新创建，因此您的实现替换可能是短暂的。此外，这可能看起来不太干净，因为您在某种程度上违反了封装：您的组件现在允许任何人编辑他们的字段之一，这是正确的，因为这正是您的测试要做的。这也是可以解决的：如果上述 hacky 技术被证明是有用的，您可能会开始将一些视图逻辑或活动逻辑抽象为全局单例样式服务中的可替换实现，或者从应用程序本身的字段：广义上，即使没有正式的框架，您也会注入依赖项。
【讨论】：