Ash*_*yan 2 java junit dbunit unit-testing hibernate
这是scanario:
我正在研究一个DAO对象,它使用hibernate标准API来形成一些复杂的查询来执行数据库上的某些任务(例如,跨多个字段的关键字搜索).
我们需要对此进行单元测试,以确保生成的查询对于各种场景都是正确的.测试它的一种方法 - 可能更好 - 将通过最后检查并模拟数据库交互来测试hibernate标准是否正确创建.然而,这是不可取的,因为它首先是有点作弊(它只是复制了代码将要做的事情),而且它也不会检查标准本身是否会导致休眠到barf,或者当它进入数据库时它会导致问题.
然后,使用选项对测试数据库运行查询.但是,由于历史原因,没有静态测试数据库(例如,代码作为代码的一部分签入的代码),并且我的项目的职权范围不允许我开始创建一个,我们必须满足于对共享开发数据库,定期使用生产数据刷新.
当这些刷新发生时,测试背后的数据也会发生变化,这将使我们的单元测试变得脆弱.我们可以通过在测试中不使用确切的数字来克服它,但这并不是真正适合测试的方式.
那么问题是:人们在这样的情况下做些什么来使测试变得不那么脆弱？我想到的一个选项是运行一个执行相同查询的本机SQL(行为 - 它不必与hibernate生成的查询完全相同)来获取预期的数字,然后运行DAO版本以查看如果它匹配.这样,查询的行为总是可以在初始本机SQL中实现,并且您将始终拥有正确的数字.
关于如何管理这种情况的这个或其他想法的任何反馈将不胜感激.
一个.
更新:
关于hsqldb/h2/derby的建议,我对它们很熟悉,但该公司尚未准备好沿着这条路走下去,只在一个测试用例上零碎地做它将不合适.
关于我之前的建议,我想详细说明一下 - 考虑这种情况:
我想确保我的相对复杂的关键字搜索返回"John Smith"的2100个匹配项.
为了找到预期的数字,我会分析我的数据库,并使用SQL查询找出数字.将该查询作为测试的一部分有什么缺点,以便您始终知道您正在测试标准的行为？
基本上问题是:如果由于某种原因你没有静态数据集进行测试,你将如何以非脆弱的方式执行集成测试？
我同意Andrey和Bedwyr的观点,从长远来看,最好的方法是创建一个专门用于测试的hsqldb数据库.如果您没有选择这样做,那么您的解决方案似乎是合适的.你不能测试一切,但你也不想测试任何东西.我已经使用这种方法几次来测试针对集成数据库等的Web服务.但是请记住,如果添加新列等,也必须维护此数据库.
你必须决定你要测试的是什么.你不想测试hibernate,你不想测试数据库是否提供你所要求的(就SQL而言).在您的测试中,您可以假设hibernate正常工作,数据库也是如此.
你说:
我们需要对此进行单元测试,以确保生成的查询对于各种场景都是正确的.测试它的一种方法 - 可能更好 - 将通过最后检查并模拟数据库交互来测试hibernate标准是否正确创建.然而,这是不可取的,因为它首先是有点作弊(它只是复制了代码将要做的事情),而且它也不会检查标准本身是否会导致休眠到barf,或者当它进入数据库时它会导致问题.
为什么要按照你给出的标准来休眠barf？因为你给它错误的标准.这不是hibernate的问题,而是使用创建条件的代码.您可以在没有数据库的情况下测试它
它到达数据库时有问题吗？通常,Hibernate会创建适合您提供的标准和数据库方言的sql,因此,任何问题都与条件有关.
数据库与hibernate所期望的不匹配？现在,您正在测试条件和数据库是否一致.为此,您需要一个数据库.但是你不再测试标准,你正在测试一切都是一致的,一种不同的测试.
实际上,在我看来,你正在进行集成测试,从标准到数据库结构的整个链条都有效.这是一个完全有效的测试.
所以,我所做的是在我的测试中创建另一个与数据库(jdbc)的连接以获取信息.我执行SQL以获取行数等,或检查插入是否已发生.
我认为你的方法是完全有效的.
| 归档时间： |
|
| 查看次数： |
1297 次 |
| 最近记录： |