0

对于使用 GemFire 的单元测试服务，我们计划在测试上下文中包含 GemFire 'Regions' 以避免模拟并对 Gemfire 服务器有任何依赖。实现这一点的最佳实践/工具是什么？

从理论上讲，以下是我们计划的选项：

服务 --> GemFire（嵌入在测试上下文中）

为了引导上下文，ContextConfiguration：添加一个引用 gfe-cache xml 的 test-applicationContext。

Junits 将加载测试上下文并引导区域，现在我们可以使用 GemFire 触发创建/获取/删除并验证结果。

4

1 回答 1

1

您所描述的是集成测试和Spring Data GemFire所做的几乎与您所描述的完全一样，尽管更直接一些（即直接将 GemFire 区域或其他 GemFire 组件注入测试类）。例如，查看GemFireTemplateIntegrationTest类及其关联的Spring (XML) config。

这对于Spring Data GemFire在测试中直接使用 GemFire 组件是有意义的。虽然，这在实际的应用程序测试套件中可能不太理想，主要是因为我相信良好的关注点分离并围绕我的应用程序使用的依赖项提供适当的外观。

换句话说，正如您在上面提到的，在应用程序中有以下（传统的 n）层......

UI -> 服务 -> DAO

服务层是纯业务逻辑和规则，与任何数据存储（包括 GemFire/Geode）的任何交互（CRUD、查询、函数执行等）都是通过 DAO 完成的。

这使得模拟 DAO 变得非常容易，因此您可以专注于服务测试点，独立于底层数据存储的行为方式测试业务逻辑和规则。

当然，重要的是要有集成测试来确保与底层数据存储（例如 GemFire/Geode）的正确交互，如果只是为了确保正确的事务行为，或者您的 OQL（查询）语句格式正确。

但是，在实施 DAO 时有很多选择。

  1. 您可以将 Region 注入您的 DAO 并直接在 Region 上执行操作（CRUD、查询等）。

  2. 如果您使用Spring Data GemFire ，您可能更喜欢使用GemfireTemplate来保护您的 DAO（s）免于直接使用 GemFire/Geode API （以防 GemFire/Geode 引入接口破坏性更改，或包装 GemFire/Geode 异常在Spring方便且一致的（跨数据存储）异常类层次结构中，如果您换出数据存储，这很有用）。有关更多详细信息，请参见此处。

  3. 最后（但并非最不重要），您可以使用Spring Data GemFire 对Spring Data Common 的Repository 抽象的扩展，并支持 GemFire/Geode。这使得实现 DAO（又名存储库）就像定义扩展GemfireRepository的接口一样简单。

您的选择取决于您喜欢的抽象级别，每个选择都会稍微改变您进行集成测试的方式。

作为最后的花絮，这也不妨碍您仍然编写真正的单元测试。

Spring Data GemFire采用自定义测试框架（带有模拟和存根）来简化涉及 GemFire 组件（例如区域、AEQ、网关等）的单元测试。这个“自定义测试框架”植根于GemfireTestApplicationContextInitializer和相关的GemfireTestBeanPostProcessor。如果您遵循逻辑，您将开始了解它是如何工作的。

这个自定义测试框架对于测试使用SDG 的 XML 命名空间创建和初始化的 GemFire 组件的有效性非常有用。然而，将配置元数据（甚至是 GemFire/Geode 组件）放入Spring 配置变得越来越流行，我希望在Spring Data GemFire 1.9中进一步增强/简化。

此外，我希望在某个时候，我已经开始的工作，将Spring Data GemFire 的自定义测试框架提升和重构为 Spring Data GemFire 的单独的顶级 Spring 项目扩展，因为已经提出了这类问题很多。

无论如何，希望这能给您一些想法，如何以简单、简洁和一致的方式为您的应用程序进行最佳测试。

干杯!

于 2016-06-20T18:01:01.353 回答