当相关数据库模式有很多约束时,如何测试数据库查询?
背景:
- 中等数据库模式(大约 70 个表),
- 它们之间有大量外键和其他约束(不为空等)。
- 所有测试的共享数据库固定装置
- 一些简单的拆卸逻辑,在每次测试后截断“触及”的表,将测试之前存在的任何内容放在那里
- 由 JPA/Hibernate/Toplink 或其他一些对象关系映射解决方案查询数据库
现在,最大的问题是我们想要向数据库添加一些记录,我们现在必须手动执行此操作,即通过sql 脚本(在相关测试之前执行)。 这会导致我们几乎每个测试都出现神秘访客问题。
你会如何处理这个问题?
我的想法如下:
- 为每个测试创建一个新的固定装置将是一种矫枉过正,因为我们确实有很多约束,
- 另一种选择是创建一些预言机,给定一个对象的存根,它将返回一个准备好的对象放入数据库中,即不违反任何约束。 当然,这个不错的解决方案并不受到我们的经理的喜爱,因为我们必须花一些时间来创建这样一个野兽。
Background:
- moderate DB schema (some 70 tables)
- with lots of foreign keys and other constraints (not null etc.) between them
- a shared DB fixture for all the tests
- some simple tear-down logic which truncates "touched" tables after each test and puts there whatever was there before the test
- the DB is queried by JPA/Hibernate/Toplink or some other object-relational mapping solution
Now, the big issue is we want to add some records to the DB we now have to do this manually, i.e. through sql scripts (which are executed before the test in question).
This leads to a Mystery Guest problem in almost each and every test we have.
How would You deal with that?
My thoughts are as follow:
- creating a fresh fixture for each and every test would be an overkill since we have really lots of constraints
- an alternative would be to create some oracle, that, given a stub of an object, would return an object ready to put into the DB, i.e. such that doesn't violate any constraint.
This nice solution, of course, is not beloved by our managers since we would have to spend a bit of time on creating such a beast.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论