java敏捷集成测试DAO ->数据库的好实践是什么？

Question

在Java环境中，针对真实数据库模式对DAO进行敏捷集成测试的当前良好实践是什么？

(所谓“敏捷”，我指的是这个问题最精简、最自动化、最简单的解决方案。)

我希望实现测试的自动化，以证明数据访问层与数据库的实际运行实例无缝集成。我们必须针对特定的供应商DB测试自定义SQL，这一点很重要。也就是说，如果我们编写T-SQL，我们想要在SQL Server上进行测试。

是否应该将单个数据库专用于所有正在运行的测试，但没有提交？或者每个测试环境都应该有一个专用的数据库？

人们如何处理安装和拆卸？DBUnit还在流行吗？Spring能帮上什么忙？

Answer 1

根据特定的供应商DB测试我们的自定义SQL是很重要的。

因此您应该为每个供应商DB创建一套测试

@RunWith(Suite.class)
@Suite.SuiteClasses({})
public class SQLServerTestSuite {

    @BeforeClass
    public static void setUpClass() throws Exception {

    }

    @AfterClass
    public static void tearDownClass() throws Exception {
        // clean database
    }

}

是否应该将单个数据库专用于所有正在运行的测试，但没有提交？

建议使用rollback命令执行命令，因为如果使用commit，您可以更改当前测试的状态，也可以更改其他测试的状态。否则，您可能会处理意外行为。

对于每个开发人员，建议使用一个database sandbox。这允许每个用户以他们认为合适的任何方式修改数据库，并使用测试来测试应用程序，而无需担心他们的测试与其他用户的测试之间的任何交互

人们是如何处理安装和拆卸的？

public class PersonTest {

    @Before
    public void setUp() {
        // set up state to run the test
    }

    @After
    public void teardown() {
       // Transaction rollback
    }

}

关于Transaction rollback pattern的好处是，不管我们对数据库内容做了什么更改，它都会使数据库处于与开始测试时完全相同的状态

DBUnit还在流行吗？

DBUnit用于将数据库表与包含预期值的XML文件进行比较。你应该记住DBUnit处理手工编码的设置。然而，尽管这种方法更加彻底，但是开发和维护这些类型的测试是非常繁琐的。此外，测试不会检测到新添加的字段或属性的缺失映射。

Spring能帮上什么忙？

Spring内置了对事务回滚模式的支持，并支持命名参数(SqlParameterSource)，该参数允许您将普通的jdbc查询外部化为多行且可读的xml文件，例如，每个供应商的数据库

<?xml version="1.0" encoding="UTF-8"?>
<queries>
    <query name="PERSON_BY_ID">
        <![CDATA[
            select 
                *
            from 
                PERSON
            where
                PERSON.ID = :integerId
        ]]>
    </query>
</queries>

请注意查询参数。它遵循JavaScript代码风格，您可以将参数类型声明为前缀。现在您可以创建一个类，在其中定义一组命名查询

public class SQLServerQuery {

    public static final String PERSON_BY_ID = "PERSON_BY_ID";

}

对于动态查询，检测查询逻辑中的bug通常很重要，比如使用<而不是<=。为了捕获这些类型的bug，我们需要编写用测试数据填充数据库的测试，执行查询，并验证它是否返回了预期的对象。不幸的是，这类测试的编写和执行都很耗时。

Answer 2

我想说的是，DAO的集成测试只需要确保ORM的QL，例如HQL，或JDBC SQL是有效的。我认为，假设查询语言本身已经针对多个驱动程序/数据库进行了彻底的测试，这是合理的。接下来，使用诸如HSQLDB这样的“内存”数据库是合理的。

"Spring Test“的目标是集成测试，它在设置IoC上下文、提供事务、设置数据库会话、创建模式并在测试后删除它、在测试后回滚事务等方面做得很好。以至于我对将我的一些数据库测试标记为集成测试持观望态度(我个人认为，只要单元测试不跨越进程边界，并且它们的设置是无摩擦的，它们就构成了一个合理的单元测试)。

另一方面，一些好的系统测试应该端到端地测试您的系统，并使用所有目标数据库进行测试。设置系统测试总是有很多工作要做，而且，因为您是在测试系统本身，所以在框架和工具包方面有很多适用的帮助。

Answer 3

我认为一个数据库(每个开发人员)应该是可以的，只要你确保在测试开始时删除你设置的数据。如果您不依赖于任何初始数据集，那么只需清除这些表即可。在这种情况下，DBUnit是一个很好的解决方案。

有时，您依赖于一些初始数据集，不是针对所有测试，而是针对少数测试，主要针对select查询。如果您依赖于某些数据集，则会变得很棘手。您仍然可以通过在每次测试开始之前运行种子数据并在测试结束时拆除来管理Dbunit，但这会使测试运行更长的持续时间。

在这种情况下，我发现更好的方法是创建一个简单的实用程序类来保存在测试开始时创建的任何新数据的id，并在测试结束时将其删除。