代码之家 › 专栏 › 技术社区 › A_M

在包含远程数据库的Oracle上测试SQL查询

mocking unit-testing oracle sql java

A_M · 技术社区 · 16 年前

我们的开发数据库(Oracle9i)使用到远程共享数据库的远程数据库链接。

这个决定是在几年前做出的,当时把一些数据库模式放在开发机器上是不实际的——它们太大了。

我们在开发机器上有一些模式,并且通过使用Oracle的数据库链接,以及开发机器上的一些同义词,使远程模式看起来像本地模式。

我有一个问题,我想测试一段SQL,它连接数据库链接两侧模式中的表。

例如(简化案例):

   select a.col, b.col
   from a, b
   where a.b_id = b.id

a在本地数据库上
B在删除数据库上
我在locale db上有一个同义词,所以“b”实际上指向b@remotedb。

由于链接的存在,在开发环境中运行查询需要很多时间。查询在生产中运行良好(我认为基于Oracle成本的优化程序无法很好地处理数据库链接)。

在过去,我们并不擅长为这些类型的查询编写单元测试——可能是由于性能不佳——所以我想开始为它们创建一些测试。

是否有人有为这样的查询编写单元测试的策略,以避免使用数据库链接的性能问题?

我通常会考虑尝试模拟远程服务的方法,但由于所有这些都在SQL查询中,所以我看不到轻松模拟删除数据库的方法。

4 回复 | 直到 16 年前

MichaelN 16 年前

您应该从开发时的产品中创建所需的所有模式的精确副本,但不需要所有数据。您应该用足够的数据填充模式,以便进行适当的测试。您还可以通过从生产服务器导出统计信息并将其导入到您要复制的模式的开发数据库,来操作优化器,使其在测试系统上的行为与生产类似。这样,查询将与您所做的数据集一起运行,但查询将使用与生产计划类似的计划进行优化。然后你可以从理论上估计它在生产中的规模。

Aaron Digulla 16 年前

将相关数据复制到开发数据库中,并在本地创建表。

理想情况下,只需构建一个测试用例,它告诉您:

SQL是正确的(它分析)
它使用几行测试数据正确运行

不要沉迷于“让我们复制所有东西”,因为这意味着你将不知道你在测试什么(以及你丢失了什么)。

如果有疑问,请创建一个表 b 只有一张唱片。如果在该区域中出现错误,请在了解错误可能出现的位置时添加更多行。

如果您想将其带到边缘,请在单元测试中创建测试表(包含所有数据)。这样,您就可以记录正在使用的测试数据。

[编辑]您需要的是一个测试数据库。不要对可以更改的数据库运行测试。理想情况下,测试应该分解整个数据库并从头开始重新创建(表、索引、数据、所有内容)作为第一步。

在这个测试数据库中,只保留定义良好的测试数据,这些数据只通过定义新的测试(而不是由某人“只是做一些事情”)来更改。如果可以,请尝试对内存中的数据库运行测试。

northpole 16 年前

我会提出具体化的观点。这些视图在本地存储远程数据。

Dori Nimit Parekh 14 年前

理论上,要进行单元测试,您可以使用根据您的测试用例创建和设计的任何控制数据集。它不必是你的生活或发展系统。假设你的设备足够便携。在进行集成测试时,您将使用当前的数据库/应用程序对其进行测试,而集成测试也可能在实时系统上进行(因此不需要数据库链接-我了解您的实时数据库位于一个位置)。

我想说的是,您可以/应该在一组可模拟不同“用例”的受控数据上测试您的单元(即,您的组件、查询或您定义为单元的任何内容),一旦您完成测试并获得令人满意的结果,那么您就可以继续进行集成+运行集成测试。

集成测试——你可以在实况环境中运行它,但是只有当你通过单元测试证明你的组件是“防弹”(如果你的公司的方法/理念没问题的话)之后——sys admin的反应是:“你是不是疯了?!“)

如果您试图回到过去,测试已经实现的单元,那么为什么要麻烦呢?如果他们已经在一个生产使用一段时间没有任何事件,那么我会说他们是好的。然而,你的单位/查询总是有可能会有一些“缓慢滴答的定时炸弹”的副作用(随着时间的累积效应)。好吧,分析影响就是答案。