对于使用Gemfire的单元测试服务，我们计划将Gemfire"区域"包括在测试中，以避免模拟并对Gemfire服务器有任何依赖性。哪些最佳实践/工具可以启用？
理论上，以下是我们计划的选项：
服务 -> gemfire（嵌入在test-context中）
bootstrap上下文，contextsconfiguration：添加一个带有GFE-CACHE XML的test-ApplicationContext。
junits将加载测试文本并引导区域，现在我们可以使用gemfire触发create/fetch/delete并验证结果。
您所描述的是集成测试，而某物 Spring Data Gemfire 几乎完全像您所描述的那样，尽管更直接地（即注入Gemfire区域或其他可能Gemfire组件直接进入测试类）。例如，查看gemfiretemplateIntegrationTest类以及它的关联弹簧（XML）config。
这对于春季数据Gemfire 直接在测试中使用Gemfire组件是有意义的。虽然，这在实际的应用程序测试套件中可能并不理想，这主要是因为我相信良好的关注点并在我的申请使用的依赖项上提供适当的立面。
换句话说，正如您所提到的，在应用程序中具有以下（传统n）层...
ui->服务 -> dao
服务层是纯业务逻辑和规则，并且与任何数据存储（包括Gemfire/Geode）（包括Gemfire/Geode）的任何交互（CRUD，查询，函数执行等）都是通过DAO进行的。
这使嘲笑DAO非常容易，因此您可以专注于服务测试的点，以独立于基础数据存储的行为来测试业务逻辑和规则。
当然，重要的是要进行集成测试，以确保与您的基础数据存储（例如Gemfire/Geode）进行适当的交互，如果仅是为了确保正确的交易行为，或者您的OQL（QUERY）语句形成良好。
但是，在实施您的dao方面有很多选择。
-
您可以将区域直接注入DAO（S）并直接在该地区执行操作（CRUD，查询等）。
-
如果您使用的是 spring data gemfire ，您可能希望使用gemfiretemplate屏蔽dao（s）免受gemfire/geode api的直接使用（如果接口破裂发生变化，由Gemfire/Geode引入，或在 Spring的中包装Gemfire/Geode Exceptions 方便且一致（跨数据存储）异常类别层次结构，如果您交换数据存储，这很有用）。有关更多详细信息，请参见此处。
-
最后（但并非最不重要的一点），您可以使用 Spring Data Gemfire的 spring Data Common的 repository抽象的扩展，并支持Gemfire/Geode。这使得实现daos（又称存储库）作为定义扩展gemfirerepository的接口。
您选择取决于您喜欢的抽象水平，每个选择都会稍微改变您对集成测试的方式。
作为最后一个花絮，这并不排除您仍在编写真实的单元测试。
春季数据Gemfire 采用自定义测试框架（带有模拟和存根）来简化涉及Gemfire组件（例如区域，AEQS，GATEWAYS等）的单元测试。此"自定义测试框架"植根于gemfireteSplicationContextInitializer和相关的GemFiretestBeanPostProcestor。如果您遵循逻辑，您将开始看到它的工作原理。
此自定义测试框架对于测试使用SDG的XML名称空间创建和初始化的Gemfire组件的有效性非常有用。但是，将配置元数据放置在Spring Config中，将配置元数据放入Spring Config，它变得越来越流行，我希望在 Spring Data Data Gemfire 1.9中进一步增强/简化。
此外，我希望在某个时候我已经开始工作，以提升和重构 spring data gemfire的自定义测试框架纳入一个单独的，顶级的春季项目扩展em> Spring Data Gemfire 已经问了很多问题。
无论如何，希望这会为您提供一些想法，如何以简单，简洁和一致的方式为您进行最佳方法测试。
欢呼！