企业集成测试夹具设置

Question

我正在尝试在使用“企业集成模式 (EIP)”编写的新在线购物系统中测试一个组件。该组件观察客户的购物行为并在此过程中提出建议。

EIP 的工作方式允许轻松编写此类组件，但我在为该组件设置测试夹具时遇到了极大的困难。在这个系统中，很多数据之间都有一定的逻辑联系，这需要它们一起变化。这转化为具有数百行设置的测试，这是不可维护的。

我现在正在评估三种解决方案：

1.为所有消息和响应对象创建我们自己的构建器：

目的： * 将测试与一些变化隔离开来。 * 允许更好的夹具代码重用。 （可以在构建器中设置一些默认值。）

优点/缺点：

每个测试仍需要大量代码来设置，但在很大程度上是面向未来的。数据一致性完全取决于程序员。

2.连接的建设者：

基本上从解决方案 1 向构建器添加一些方法来填充彼此的字段。例如，订单生成器上可能有生成搜索和页面查看历史记录的方法。

目的： * 进一步减少每次测试中的夹具设置量 * 提高灯具的一致性

优点/缺点：

构建器非常复杂，可能会成为他们自己的维护问题。

3. 模拟与真实服务的交互

目的：类似于方案2

优点： * 数据会更加真实和一致 * 更容易设置详细的测试数据（例如页面浏览历史）

缺点： * 非常复杂且高度依赖外部 * 用于描述/执行模拟操作的代码可能一样长 * 运行缓慢

4.本地（重新）实现的服务

目的：

• 通过在本地重新实现简单版本的服务来解决解决方案 3 中的外部依赖性
• 通过从最终结果推断操作来减少所需的测试代码数量（与解决方案 3 相比）（参见解决方案 2）

优点/缺点： * 比方案 3 更可靠，但需要大量实现

我的问题：

有更好的解决方案吗？如果不是，你会选择哪一个？另外，如果这里选择的方法将来应用于所有其他服务，您会选择不同的方法吗？

Answer 1

根据我测试严重依赖数据的服务的经验，这里有一些建议：

1. 绝对使用真实数据，而不是测试数据。我想你已经提到过手工模拟数据可能会非常痛苦，因为它经常变化并且可能很复杂/很大。

2. 能够快速重新生成真实数据。编写一个工具来进行一次数据转储并使用它并不难，但理想情况下，当数据模型发生变化时，您可以轻松地获取另一个数据快照并使用它。

3. 避免使用复杂的代码。你已经涵盖了这一点。如果复杂性太大，没有人会跟上测试的质量。

我暂时确定的我喜欢的方法如下：

1. 确保所有数据库调用/外部依赖项都位于接口后面。这允许您模拟数据。好像你已经搞定了。

2. 创建一个接口的特殊实现，它做两件事：a) 进行实时数据库调用，b) 将数据库调用的结果保存到 JSON 文件。

3. 当您需要创建真实数据的快照时，您可以将给定接口的生产实现替换为 (2) 中的接口。然后，您会浏览一些用例并将 JSON 文件写入磁盘。

4. 您的测试启动代码只需要从磁盘读取 JSON 并水合对象。

这对我来说非常有效，因为它允许快速复制真实数据，并且在数据更改时很容易更新。

显然这涉及到一些工作，但所需的代码并不是非常复杂。