使用jUnit进行DAO测试的设计模式

时间:2012-10-09 14:07:44

标签: design-patterns junit dao

我正在寻找使用jUnit测试DAO类的最佳实践。我的DAO类有几个典型的DAO方法,如createUser(用户用户),deleteUser(长id),updateUser(用户用户),findUserById(长id)......

所以createUser可能很简单,我可以创建一个用户并检查它之后是否有id。如果是,测试将通过。 或者您是否愿意创建用户,之后从数据库中读取用户并检查是否存在 1)找到用户 2)来自返回用户的实例变量与之前保存的用户相同

那么deleteUser函数呢?它需要一个ID,但为了获得ID,我首先要创建一个用户。那怎么做?使用测试方法中的testCreateUser方法或DAO类的createUser方法?

与updateUser(用户用户)相同,我需要首先更新用户并找到我首先需要Id的findUserById(Long id)。

我认为我的要求非常普遍,所以我想知道是否有类似于使用jUnit测试DAO的设计模式。

谢谢,保罗

4 个答案:

答案 0 :(得分:2)

恕我直言,没有这样的设计模式来进行JUnit测试。您需要参考最佳实践。

例如,在下面的情况下,在删除之前不要使用testCreateUser方法来创建用户。您必须使用DAO类。每个测试用例方法都是相互独立的。

  

那么deleteUser函数呢?它需要一个ID,但按顺序   获取我首先要创建用户的ID。那怎么办   这个?使用测试方法中的testCreateUser方法或   来自DAO类的createUser方法?

现在,要解决您的问题,您可以使用setUp和tearDown方法。在setUp方法中,您可以创建要测试的模拟对象,在tearDown中可以删除它们。如果这样做,每个测试方法将获得您可以测试的相同模拟数据集。

答案 1 :(得分:1)

我通常的方法是在同一测试中使用DAO的其他方法。例如

user = UserStore.create(...);
id = user.id();
loadedUser = UserStore.load(id);
assertThat(loadedUser, eq(user));

如果你采用这种方法,单元测试中的“单位”就是整个类,而你通常一次单元测试一个函数。这是可以接受的,并将导致经过良好测试的课程。这种方法的问题是失败的测试可能是由于UserStore.create或UserStore.load中的错误,但我发现对于小类,它并不难调试并且往往工作得很好。我尝试过其他方法,我在测试后手动检查数据库,但我发现额外的工作通常不值得。

一些框架,如Rails,采用不同的方法。它们为您提供了一种在测试运行之前使用数据为数据库设定种子的方法。这很好用,因为框架使它变得简单。也许这将成为常态,因为更多工具为这种方法提供支持。

答案 2 :(得分:1)

IMO单元测试应该能够独立运行。

因此,例如删除测试将首先创建一个用户然后将其删除并检查它是否已不存在(通过尝试加载它)。

依赖以前的测试并不是一个好方法,因为如果之前的测试因任何原因失败,下一次测试也将失败。

答案 3 :(得分:1)

您可以使用内存数据库在每次测试之前填充测试数据,并在测试执行完成后丢弃。看看Derby

另一件需要考虑的事情是,你真的要对你的DAO层进行单元测试吗? Dao不应该按照定义包含业务逻辑,最终会测试持久性框架。