2013-06-19 29 views
5

我只是想知道,测试JDBC相关方法的最佳方法是什么?如添加用户,禁止用户等在JUnit中测试JDBC查询

(使用JUnit)

我应该把我所有的无效方法布尔值,如果他们的工作,如果他们没有他们返回true,false和在我的JUnit测试中相应地声明这些值?

这只是寻找最佳实践的一般问题。

谢谢!

+0

一般来说,我建议这是一个集成测试的省份。使用内存数据库(如H2)代替常规数据库,并断言在调用DAO方法后表中包含预期的行。 –

回答

7

我个人发现一个很棒的工具是Mockito。你可以模拟JDBC返回给你什么,所以你可以说给定了一个特定的查询和参数,你会得到一个特定的值。

你不应该修改你的代码来使它适用于单元测试,它应该可以在生产和测试中以完全相同的方式工作。

您也可以考虑在测试阶段开始时使用内存数据库(如Derby)和加载值,以便知道其中存在的值。尽管在执行时间方面,嘲笑可能会更快。

+0

好的,我会尝试Mockito出来谢谢! – user2297666

+0

如果你这样做,你将不会测试你的数据库代码 - 你将测试所有那些取决于你的数据库代码的东西,而不是实际的DB代码本身。那是你想要做的吗? – DaveH

1

在单元测试中访问数据库通常不是一个好主意。我认为最好是模拟数据库连接并检查是否调用了正确的查询。原因不包括数据库更改和查询不再工作的情况,但通常情况下很少发生这种情况。

1

我觉得很简单的CRUD方法不需要通过单元测试来测试。只需运行该方法,然后检查表格。 更复杂的测试将覆盖基本的CRUD操作。

但是,我已经阅读了代码,其中创建/查找操作在一个方法(如集成测试)中进行了测试。然后查找的结果与创建请求进行比较。

编辑:您还可以看看DB Unit

2

当我写这样我重视,我将针对运行(而不是一个内存数据库),实际的数据库测试。我的大部分代码都使用存储过程或其他数据库特定的功能,这些功能不一定受德比支持。

无论这些是单元测试还是集成测试,我都不知道。但他们是重要,所以我更喜欢让他们内置到持续集成周期。

如果您确实使用持久性数据库,那么您确实有一些额外的事情需要担心。在测试运行之前,您需要知道数据的状态,并且应该尽可能地在每次测试运行时将其恢复到已知状态。如果你不这样做,你的测试将不会彼此独立,并且你将开始在套件的后期发现测试,由于之前的测试失败而开始失败。