我正在尝试测试使用“企业集成模式（EIP）”编写的新在线购物系统中的组件。该组件会观察客户的购物行为，并在此过程中提出建议。
EIP的工作方式允许轻松编写这样的组件，但是我在为这个组件设置测试夹具时遇到了极大的困难。在该系统中，许多数据彼此具有某种逻辑连接，这要求它们一起变化。这转化为具有数百行设置的测试，这是不可维护的。
1.为所有消息和响应对象创建自己的构建器：
目的： *根据一些变化隔离测试。 *允许更好的夹具代码重用。 （可以在构建器中设置一些默认值。）
优点/缺点：
每个测试仍然需要大量的代码来设置，但在很大程度上是面向未来的。数据一致性完全取决于程序员。
2.已连接的构建者：
基本上从解决方案1向构建器添加一些方法以填充彼此的字段。例如，订单构建器上可能有方法来生成搜索和页面视图历史记录。
目的： *进一步减少每次测试中的夹具设置量 *提高灯具的一致性
优点/缺点：
施工人员非常复杂，可能会成为他们自己的维护问题。
3.模拟与真实服务的互动
目的：类似于解决方案2
优点： *数据将更加真实和一致 *更容易设置精细的测试数据（例如页面查看历史记录）
缺点： *非常复杂且高度依赖外部 *用于描述/执行模拟操作的代码可能同样长 *运行缓慢
4.本地（重新）实施的服务
目的：
优点/缺点： *比解决方案3更可靠，但需要大量实施
有更好的解决方案吗？如果没有，你会选择哪一个？此外，如果此处选择的方法将来会应用于所有其他服务，您会选择不同的方式吗？
答案 0 :(得分：1)
根据我测试严重依赖数据的服务的经验，这里有一些建议：
绝对使用真实的数据，而不是测试数据。我想你已经提到过，手动模拟数据可能会非常痛苦，因为它经常变化并且可能很复杂/很大。
能够快速重新生成实际数据。编写一个工具来进行一次性数据转储并使用它并不困难，但理想情况下，当数据模型发生变化时，您可以轻松获取另一个数据快照并使用它。
避免复杂的代码。你已经涵盖了这一点。如果复杂性太大，没有人会保持测试的质量。
我暂时采用的方法是：
确保所有数据库调用/外部依赖项都位于接口后面。这允许您模拟数据。好像你有这个。
创建一个接口的特殊实现，它执行两项操作：a）进行实时数据库调用，b）将数据库调用的结果保存到JSON文件。
当您需要创建实际数据的快照时，可以从（2）中换出给定接口的生产实现。然后，您将完成一些用例并将JSON文件写入磁盘。
您的测试启动代码只需要从磁盘读取JSON并为对象加水。
这对我来说非常有用，因为它可以快速复制真实数据，并且在数据发生变化时很容易更新。
显然有一些工作涉及，但所需的代码并不是非常复杂。