每当讨论测试策略时，就会弹出同步问题。 基本上-由于mokas给开发人员增加了额外的负担，并且还使mooks脱离了实际的依赖关系。
那么，以哪种方式对我们来说确保Moka与实际实现的同步更便宜？
对于同步，我们可以编写一个测试，对mok和real实现执行相同的检查。
看起来像这样（我写的时候没有DI，但是有了DI，它更简单，更正确）：
public abstract class AbstractValidOrderDaoTest(){ Dao dao; public abstract arrange(); @Test public void whenValidOrderInDb_thenReturnValidOrder(){ arrange(); Order order = dao.retrieve(); assertNotNull(order); assertNotNull(order.getCustomerName());
OrderDaoTest适用于具有基础模拟或真实依赖性的真实对象，而ValidOrderDaoTest适用于模拟。
如果ValidOrderDataSource是真实的数据库，则OrderDaoTest将位于单独的程序包中，并作为集成测试的一部分运行，例如，在更新数据库时可能会不时崩溃。 这不应干扰CI \ CD。
如果ValidOrderDataSource是模拟数据库，则OrderDaoTest将与其余的单元测试一起启动。
由于模拟同步涉及测试真实的类，因此对于
真正的类将不得不涉猎其基础依赖。 此外，潜在的Mok成瘾行为应根据上层Mok的情况来进行。 就我们而言
ValidOrderDataSource。
如果您考虑一下，这是有道理的-任何有关高级类行为的陈述都隐含了底层情况中的某些情况。 如果控制器从服务中返回某些信息，那么如果基础可以提供它，那将是很好的。
相反，较高级别的人通常会对较低级别的人抱有不切实际的想法，因此删除不必要的脚本也不错。
递归建议为了使顶级模拟程序同步，您需要启动所有基础模拟程序的同步，直到外部依赖项为止。
这使得系统规范更加透明，因为更一般和抽象的场景依赖于更多的私有场景。
另请注意，有些Moka不需要同步。 即 我们没有需要交叉测试的真正实现。 这适用于主要错误方案。 EmptyResultException_Datasource例如 这大大减少了所需的交叉测试次数。
真正的外部依赖项（例如队列，外部服务，数据库）当然需要同步-尤其是关于它们获取和返回的数据。
如果外部服务突然发生更改（这通常在开发阶段），那么如果不编写同步测试，我们将无法检查其行为。
在劳动强度方面。 就其本身而言，我们已经有了一个带有一些任意模拟依赖项的真实类测试。 与非同步测试相比，我们需要做一些事情。
- 在抽象测试中突出行为和主张
- 对摩卡进行特定测试
- 修复真实类测试中的模拟依赖项
- 如果需要，请以递归的方式完全重复到外部依赖项。