单元测试数据库驱动的应用程序的最佳策略是什么？


What's the best strategy for unit-testing database-driven applications?

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

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

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

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

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

有些人指出，这两种策略都依赖于特定的数据，单元测试应该只测试功能。为此，我见过建议：

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

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

相关讨论

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

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

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

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

    • 加载生产数据库副本：
    这是我上一份工作中使用的方法。这是几个问题的巨大痛苦原因：

  • 副本将从生产版本中过时
  • 将对副本的架构进行更改，并且不会传播到生产系统。在这一点上，我们有不同的模式。不好玩。

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

    相关讨论

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

    • 它使您可以考虑在测试数据库中保留哪些数据以及原因。将生产数据库运送到测试系统只是"我不知道我在做什么或为什么，如果有什么东西坏了，那不是我！" ;)
    • 它确保可以在新的位置轻松地重新创建数据库(例如，当我们需要从生产中复制错误时)
    • 它极大地帮助了DDL文件的质量。

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

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

    相关讨论

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

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

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

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

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

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

    即使有工具允许你以某种方式模拟你的数据库(例如jOOQ的MockConnection，这可以在这个答案中看到 - 免责声明，我为jOOQ的供应商工作)，我建议不要使用复杂的查询。

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

    • 句法
    • 复杂
    • 订单(！)

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

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

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

    我正在使用第一种方法，但有点不同，可以解决您提到的问题。

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

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

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

  • 非常接近测试
  • 显式(使用SQL文件获取数据使得查看哪些数据被哪个测试使用很成问题)
  • 将测试与无关的变化隔离开来。

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

    为了弄清楚它在实践中意味着什么，可以考虑一些DAO的测试，该测试使用Comment到Post来写入Authors。为了测试这种DAO的CRUD操作，应该在DB中创建一些数据。测试看起来像：

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    @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文件相比，这有几个优点：

  • 维护代码要容易得多(例如，在许多测试中引用的某些实体中添加强制列，例如Author，不需要更改大量文件/记录，只需更改构建器和/或工厂)
  • 特定测试所需的数据在测试本身中描述，而不是在其他文件中描述。这种接近度对于测试可理解性非常重要。

    • 回滚与提交

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

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

    相关讨论

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

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

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

    Acolyte是我的框架，其中包括用于此类模型的JDBC驱动程序和实用程序：http：//acolyte.eu.org。