更新数据库表的方法应该如何进行单元测试?

我做第二件事,即通过更新记录来测试更新,然后将其读回并验证值是否与您输入的值相同。在事务中执行更新和读回,然后回滚,以避免对数据库产生永久性影响。我不认为这是测试框架代码,就像我不认为它是测试操作系统代码或网络代码一样。..框架(如果你指的是非特定于应用程序的数据库访问层组件)应该单独进行测试和验证。

还有第三种选择,即使用模拟数据库访问对象,该对象知道如何响应更新,就像它已经连接到实时数据库一样,但它并没有真正对数据库执行查询。

此技术可用于补充对实时数据库的测试。这与对实时数据库进行测试不同,也不应该取代这种测试。但它至少可以用来测试类对数据库更新的调用是否使用了正确的输入。它通常也比在真实数据库上运行测试快得多。

你必须测试代码对数据的实际影响,以及它是否符合验证规则等,而不仅仅是没有引发异常——这有点像检查一个过程是否编译!

它 是 执行插入、更新或删除(DML)的困难测试数据库代码,因为测试会改变它运行的环境,即数据库。连续多次运行相同的过程可能(而且可能应该)每次都会产生不同的结果。这与单元测试“纯代码”非常不同,你可以运行数千次,但总是得到相同的结果,即“纯代码 基于决定论的 ,执行DML的数据库代码不是。

因此,您确实经常需要构建一个“框架”来支持数据库单元测试,即在正确的状态下设置一些测试数据并在测试运行后进行清理的脚本。

如果您不是手动写入数据库,而是使用框架(jvm、.net framework等),则可以安全地假设框架正确写入数据库。你必须测试的是你是否正确使用了框架。

只需模拟数据库方法和对象。测试您是否正在调用它们并正确检索数据。这样做将使您有机会更轻松地编写测试,更快地运行它们,并使它们并行运行,完全没有问题。

他们不应该 单元 测试了!这些方法的全部意义在于 整合 与外部世界(即数据库)。所以,确保你的 整合 测试击败了那些你知道的方法,而忘记了单元测试。

它们应该如此简单,以至于它们“显然没有错误”,不管怎样,如果它们不是,你应该把它们分成一个有逻辑的部分和一个只接受一个值并将其粘贴在数据库中的愚蠢部分。

记住:目标是100% 测试 覆盖率,不是100% 单元测试 新闻报道;这包括 所有 您的测试包括:单元、集成、功能、系统、验收和手册。

如果更新逻辑很复杂,那么你应该做#2。

在实践中,真正对复杂的计算和更新进行单元测试的唯一方法 比如计算一组客户交易的银行手续费, 是在开始时将一组表初始化为已知值 单元测试和最后的预期值测试。

我用 DBUnit 要向数据库加载数据,请执行更新逻辑,最后从数据库中读取更新的数据并进行验证。基本上是#2。