【发布时间】：2015-02-12 23:26:28
【问题描述】：
jOOQ 3.5.0
我目前正在尝试为使用 jOOQ 生成的 DAO 对象的资源编写单元测试。
我注意到 DAO 层次结构中的一个基类 (DAOImpl) 有许多 final 方法，这使得它对模拟不友好（我不包括像 Powermock 这样的字节码操纵器作为解决方案）。我目前正在使用 MockConnection 和 MockDataProvider 模式来填充我的 DAO，但对于断言 DAO 方法调用来说，这似乎有点低级。
例如，我的资源正在调用 FooDao.createFoo(foo)，而我在测试中的拦截点是 MockDataProvider.execute(...)，它为我提供了一个带有原始 SQL 的上下文对象和一个值的绑定对象数组。
为了让测试断言 create 已被调用，我需要评估原始 sql。当 DAO 有可以断言的漂亮、流畅的方法时，做这样的事情似乎很浪费。
所以我的问题是：有没有更好的方法来单元测试 DAO 的使用？似乎我需要很多样板才能测试一个简单的合同....
FooDao fooDao = createMock(FooDao.class);
....
when(fooDao.fetchById(id)).thenReturn(foo);
比example in the docs 更可取。
【问题讨论】：
-
是什么让您无法使用 Powermock？
-
或者，您可以使用
DAO代替DAOImpl并编程（即模拟）接口吗？ -
@Xaerxess
FooDao和DAO之间的细节太多。这对我来说意味着每个 DAO 都需要大量样板，以便能够编写干净的测试。 -
@LukasEder PowerMock 是临时解决方案，但我想将其换成更清洁的东西。这类工具会导致构建/测试套件（使用回收的 JVM 等）出现问题。 API 通过 final 方法锁定是很好的设计，但是如果没有这些方法，生成的接口将大大有助于轻量级单元测试。
-
@markdsievers：这不会导致一个客观的答案:) 但“更清洁的东西”和“嘲笑”是两个根本相反的概念。当您想要模拟事物时，您总是会遇到 Java 语言或 JVM 的限制，因此您不妨求助于字节码操作和检测。仅仅模拟的想法与封装和其他核心 OO/Java 设计工具根本相反，即使 TDD 的拥护者喜欢假装不是这种情况（在 Java 的上下文中）。例如，jOOQ 的大部分内容是故意包私有的，甚至是静态的......
标签： java sql unit-testing mocking jooq