我的集成测试是否应该重用持久性库来访问数据库？ [关闭]答案

【问题标题】：Should my integration tests reuse persistence library to have access to db? [closed]我的集成测试是否应该重用持久性库来访问数据库？ [关闭]
【发布时间】：2018-05-23 11:02:35
【问题描述】：

我有一个包含 IUserRepository 抽象的 DDD.IdentityAccess.Domain 实现。还有另一个 dll -> DDD.IdentityAccess.Persistence.Sql 包含 IUserRepository 抽象的实现。现在，我想一直测试我的 IdentityAccess -> Api -> DomainLogic -> 数据库。让我们看一个“CreateUser”用例。我通过我的 httpClient 调用“CreateUser”，然后我想查询 db 以检查用户是否实际添加到 db。我的rest api上没有'user/id'操作，所以唯一的选择是使用DDD.IdentityAccess.Persistence.Sql，但它会给DDD.IdentityAccess.Domain带来依赖。我应该重用这个 dll，还是创建另一个与域无关的 DAL？

【问题讨论】：

真正由您决定什么样的设计决策和权衡是有意义的！做你认为能帮助你提高工作效率的事情！
我明白你的意思，因为我也想过。您正在测试适配器，因此为了检查写入测试，我不会使用读取，因为它也属于适配器..您应该使用数据库的其他程序读取数据库，或者例如检查写入一个数据库触发器监听插入。
Gerard Meszaros 在他的书“xUnit 测试模式”第 172-173 页中也谈到了这一点。他提到“DBUnit”作为测试工具插入数据以测试“读”操作，并检查数据库的内容以测试“写”操作。

标签： domain-driven-design integration-testing ddd-repositories hexagonal-architecture

【解决方案1】：

这与域驱动设计的关系不大，而是与组织测试设置有关。

集成测试的编写成本很高，但可以通过显示多个组件按预期协同工作来带来巨大的价值。这是一个权衡。

也就是说，如果我理解正确，你的问题是你应该模拟 sql 数据访问对象还是一直到数据库，执行相同的 sql 语句。

这里没有正确或错误的答案。如果重点是测试业务逻辑，那么专注于测试领域和模拟数据库访问层。

如果重点是测试一个简单的保存操作是否从上到下工作，那么不要模拟。（但当然要使用测试数据库。）

【讨论】：

不，我的问题是我是否应该在我的集成测试项目中重用持久性库，或者创建一个具有贫血实体的新持久性库以不引用我的域类...
编写一组单独的实体听起来违反直觉，尤其是对于集成测试。所以，不，而不是。
实体是什么意思？具有行为的领域模型？因为我的持久层引用了域模型，这就是让我不确定的原因......
实体是可以从数据库中存储和检索的域类。域类是 DDD 的核心（以及作为关键字添加到问题中的六边形架构）。因此，没有它们就很难编写任何测试。没有一个明确的答案，因为你应该权衡你的情况的利弊。但作为一般规则，您可以在集成测试中包含您的域类。对于专注于单个类的纯单元测试，您可以考虑模拟该类的依赖关系。