提问



我使用很多Web应用程序,这些应用程序由后端不同复杂程度的数据库驱动。通常,有一个与业务和表示逻辑分开的ORM层。这使得业务逻辑的单元测试相当简单;事情可以在离散模块中实现,测试所需的任何数据都可以通过对象模拟来伪造。[8]


但是测试ORM和数据库本身一直充满了问题和妥协。


多年来,我尝试了一些策略,其中没有一个完全满足我。



  • 使用已知数据加载测试数据库。针对ORM运行测试并确认正确的数据返回。这里的缺点是您的测试数据库必须跟上应用程序数据库中的任何架构更改,并且可能不同步。它还依赖于人工数据,并且可能不会暴露由于愚蠢的用户输入而发生的错误。最后,如果测试数据库很小,它就不会显示缺失索引等效率低下的问题。(好吧,最后一个不是真的应该使用单元测试,但它并没有受到伤害。)

  • 加载生产数据库的副本并对其进行测试。这里的问题是您可能不知道在任何给定时间生产数据库中的内容;如果数据随时间变化,您的测试可能需要重写。



有些人指出,这两种策略都依赖于特定的数据,单元测试应该只测试功能。为此,我看到了建议:



  • 使用模拟数据库服务器,并仅检查ORM是否正在发送正确的查询以响应给定的方法调用。



您使用了哪些策略来测试数据库驱动的应用程序?什么对你有用?

最佳参考


我实际上已经使用了你的第一种方法取得了相当大的成功,但我认为这种解决方案可以解决你的一些问题:



  1. 保留整个架构和脚本,以便在源代码管理中创建它,以便任何人都可以在签出后创建当前数据库架构。此外,将样本数据保存在由部分构建过程加载的数据文件中。当您发现导致错误的数据时,请将其添加到您的示例数据中,以检查错误是否会重新出现。

  2. 使用持续集成服务器构建数据库架构,加载示例数据并运行测试。这就是我们如何使测试数据库保持同步(在每次测试运行时重建它)。虽然这要求CI服务器具有对其自己的专用数据库实例的访问权和所有权,但我说每天建立3次我们的数据库模式可以极大地帮助找到可能在发送之前就找不到的错误(如果不是以后的话) )。我不能说我在每次提交之前重建模式。有没有人?用这种方法你不必(也许我们应该,但如果有人忘记,这不是什么大问题)。

  3. 对于我的小组,用户输入是在应用程序级别(而不是db)完成的,因此通过标准单元测试进行测试。



加载生产数据库副本:

这是我上一份工作中使用的方法。这是几个问题的巨大痛苦原因:



  1. 副本将从生产版本
  2. 过期
  3. 将对副本的架构进行更改,并且不会传播到生产系统。在这一点上,我们有不同的模式。没有乐趣。



模拟数据库服务器:

我们目前的工作也是这样做的。在每次提交之后,我们对注入了模拟db访问器的应用程序代码执行单元测试。然后我们每天三次执行上面描述的完整db构建。我绝对推荐这两种方法。

其它参考1


由于以下原因,我总是针对内存数据库(HSQLDB或Derby)运行测试:



  • 它会让您考虑在测试数据库中保留哪些数据以及原因。把你的生产数据库搬进一个测试系统会转换成我不知道我在做什么或者为什么,如果有什么东西坏了,那就不是我了! ;)

  • 确保数据库可以在新地方轻松重建(例如,当我们需要从生产中复制错误时)

  • 它极大地提高了DDL文件的质量。



一旦测试开始,内存数据库就会加载新数据,在大多数测试之后,我调用ROLLBACK来保持稳定。 始终保持测试数据库中的数据稳定!如果数据一直在变化,你就无法测试。


数据从SQL,模板DB或转储/备份加载。如果它们是可读格式,我更喜欢转储,因为我可以将它们放在VCS中。如果这不起作用,我使用CSV文件或XML。如果我必须加载大量数据......我不会。您永远不必加载大量数据:)不适用于单元测试。性能测试是另一个问题,适用不同的规则。

其它参考2


我一直在问这个问题很长一段时间,但我认为没有灵丹妙药。


我目前所做的是模拟DAO对象并保持内存表示一个良好的对象集合,这些对象代表可以存在于数据库中的有趣数据案例。


我用这种方法看到的主要问题是你只覆盖与DAO层交互的代码,但从不测试DAO本身,根据我的经验,我发现在该层上也发生了很多错误。我还保留了一些针对数据库运行的单元测试(为了在本地使用TDD或快速测试),但这些测试从未在我的持续集成服务器上运行,因为我们不为此目的保留数据库,我认为在CI服务器上运行的测试应该是自包含的。


我觉得非常有趣的另一种方法,但并不总是值得花费一点时间,就是在单元测试中运行的嵌入式数据库上创建用于生产的相同模式。


即使毫无疑问,这种方法可以提高您的覆盖率,但也有一些缺点,因为您必须尽可能接近ANSI SQL,以使其适用于您当前的DBMS和嵌入式替换。


无论你认为什么与你的代码更相关,有一些项目可以使它更容易,如DbUnit。[9]

其它参考3


即使有工具允许你以某种方式模拟你的数据库(例如jOOQMockConnection,这可以在这个答案中看到 - 免责声明,我为jOOQ的供应商工作),我会建议不来模拟具有复杂查询的大型数据库。[10] [11]


即使您只想集成测试您的ORM,请注意ORM向您的数据库发出一系列非常复杂的查询,这些查询可能会有所不同。



  • 语法

  • 复杂性

  • 订单(!)



模拟所有这些产生合理的虚拟数据是非常困难的,除非你实际上在你的模拟中建立一个小数据库,它解释传输的SQL语句。话虽如此,使用一个众所周知的集成测试数据库,你可以轻松地重置使用众所周知的数据,您可以使用它来运行集成测试。

其它参考4


我使用第一个(对测试数据库运行代码)。我看到你用这种方法提出的唯一实质性问题是模式失去同步的可能性,我通过在我的数据库中保留版本号并通过应用每个版本增量的更改的脚本来进行所有模式更改来处理。


我还首先针对我的测试环境进行所有更改(包括数据库模式),因此它最终成为另一种方式:在所有测试通过后,将模式更新应用于生产主机。我还在我的开发系统上保留了一对独立的测试与应用程序数据库,这样我就可以在触摸真实的生产框之前验证数据库升级是否正常工作。

其它参考5


对于基于JDBC的项目(直接或间接,例如JPA,EJB,...),您可以模拟不是整个数据库(在这种情况下,最好在真实的RDBMS上使用测试数据库),但只能在JDBC级别进行模型化。


优势就是抽象,就像这样,因为JDBC数据(结果集,更新计数,警告......)与后端无关:你的prod db,测试数据库,或者只是为每个测试提供的一些模型数据案件。


通过针对每种情况模拟的JDBC连接,无需管理测试数据库(清理,只需要一次测试,重新加载固件,......)。每个模型连接都是隔离的,无需清理。每个测试用例中只提供最少的必需装置来模拟JDBC交换,这有助于避免管理整个测试数据库的复杂性。


Acolyte框架包括JDBC驱动程序和这种模型的实用程序:http://acolyte.eu.org。[13]

其它参考6


我使用第一种方法,但有点不同,可以解决你提到的问题。


运行DAO测试所需的一切都在源代码管理中。它包括用于创建数据库的模式和脚本(docker非常适合这种情况)。如果可以使用嵌入式DB - 我用它来提高速度。


与其他描述的方法的重要区别在于,测试所需的数据不是从SQL脚本或XML文件加载的。一切(除了一些有效的常量字典数据)是由应用程序使用实用程序函数/类创建的。


主要目的是使测试使用的数据



  1. 非常接近测试

  2. 显式(使用SQL文件获取数据会使查看哪些数据被哪些测试用起来很成问题)

  3. 将测试与无关的更改隔离开来。



它基本上意味着这些实用程序允许在测试本身中仅以声明方式指定测试所必需的内容,并省略不相关的内容。


为了弄清楚它在实践中意味着什么,可以考虑一些DAO的测试,它与AuthorsPostAuthors编写的Comment一样。为了测试这种DAO的CRUD操作,应该在DB中创建一些数据。测试看起来像:


@Test
public void savedCommentCanBeRead() {
    // Builder is needed to declaratively specify the entity with all attributes relevant
    // for this specific test
    // Missing attributes are generated with reasonable values
    // factory's responsibility is to create entity (and all entities required by it
    //  in our example Author) in the DB
    Post post = factory.create(PostBuilder.post());

    Comment comment = CommentBuilder.comment().forPost(post).build();

    sut.save(comment);

    Comment savedComment = sut.get(comment.getId());

    // this checks fields that are directly stored
    assertThat(saveComment, fieldwiseEqualTo(comment));
    // if there are some fields that are generated during save check them separately
    assertThat(saveComment.getGeneratedField(), equalTo(expectedValue));        
}


与SQL脚本或带有测试数据的XML文件相比,这有几个优点:



  1. 维护代码要容易得多(例如,在许多测试中引用的某些实体中添加强制列,例如Author,不需要更改大量文件/记录,只需更改构建器和/或工厂)

  2. 特定测试所需的数据在测试本身中描述,而不是在其他文件中描述。这种接近度对于测试可理解性非常重要。



回滚还是不回滚



我发现测试在执行时会提交更方便。首先,如果提交从未发生,则无法检查某些效果(例如DEFERRED CONSTRAINTS)。其次,当测试失败时,可以在DB中检查数据,因为它不会被回滚恢复。


因此,这有一个缺点,即测试可能会产生损坏的数据,这将导致其他测试失败。为了解决这个问题,我尝试隔离测试。在上面的示例中,每个测试都可以创建新的Author,并且创建与其相关的所有其他实体,因此很少发生冲突。为了处理可能被破坏但不能表示为DB级别约束的剩余不变量,我使用一些编程检查来检查每次测试后可能运行的错误条件(它们在CI中运行但通常在本地关闭以获得性能原因)。