时间戳

首页 > 解决方案 > 涉及数据库的单元测试（插入/更新/选择）

database - 涉及数据库的单元测试（插入/更新/选择）

问题描述

期待了解该领域和背景下的最佳实践。

两种情况

  1. 我有一个用 Java 和 Spring 编写的组件，我在其中获取一些数据，将其转换为另一种涉及核心业务逻辑和插入/更新 Cassandra DB 的格式。
  2. 另一个 java 组件从该数据库读取数据，在其上运行业务逻辑并处理其他一些功能。

现在在编写单元测试用例时，我可以想到以下两种高级方法

  1. 我可以使用 Mockito 或类似工具来模拟 DAO 对象，这样在对 DAO 对象执行获取和保存操作时，我实际上不会调用 DB。
  2. 我实际上不能模拟并让连接到数据库。
  3. 我们仅在构建快照期间连接到数据库（对于少数测试用例）

然而 -

对于 (1) - 我们实际上并没有测试数据是否正确存储/更新。对于 (2) - 在单元/回归中这样做不是一个好主意，因为我们不想每次执行 mvn install 或构建时都连接到 DB 对于 (3) - 这听起来像是一个更好的选择是可行的。

问题是 - 作为单元测试或回归测试的一部分或在构建期间测试数据库操作的最佳实践是什么。我们应该总是嘲笑这些电话吗？

标签： databaseunit-testingmockito

解决方案

您的场景非常抽象，因此答案也是：

您描述的测试场景似乎是单元测试和集成测试问题的混合体。在单元测试中，您希望深入测试业务逻辑（计算，但最好不要与其他组件交互），以发现计算部分中的错误。对其他组件（如数据库）的依赖令人不安。然而，在集成测试中，您正在寻找不同组件之间交互的错误。

因此，第一步是重新设计您的组件，以便将代码的计算主导部分与交互主导部分分开。理想情况下，您最终会得到许多与其他组件没有交互的计算主导部分的函数/方法，这样您就可以通过单元测试来测试这些函数，而无需模拟。在不太理想的情况下，您仍然有一些交互，但只剩下很少的交互，因此至少减少了模拟的工作量。

重新设计后获得的第二种功能/方法是交互主导的功能。理想情况下，交互主导的函数没有计算代码，而只包含与其他组件的交互。然后，对于这些函数，单元测试没有意义，因为这种类型的代码可能包含的唯一错误是错误的顺序调用函数（或执行 DB 操作），调用错误的函数（或 DB 操作），以错误的顺序传递参数，传递不兼容的参数，接收意外数据等，所有这些错误都无法通过单元测试找到，但可以通过集成测试找到。

推荐阅读