是否有一个类似dbunit的框架不能吸引java / scala?

我正在考虑制定一个新的轻量级数据库人口框架。 我绝对讨厌dbunit。 在我做之前,我想知道是否有人已经做到了。

我不喜欢dbunit的东西:

1)不build议使用最简单的写入和上手格式。 他们希望你使用臃肿的格式。 有些甚至需要XML模式。 好吧,无所谓了。

2)它们不是按照你写的顺序填充行,而是按照顺序在xml文件中定义表格。 这是非常糟糕的,因为您不能以外键约束不会导致问题的方式来sorting数据。 这只是迫使你去完全把它们关掉的麻烦。

这也浪费了时间,使你的junit基类膨胀,包括禁用外键约束的代码。 您可能需要testing数据库types(hsqldb等),并以特定于数据库的方式禁用它们。 这太糟糕了。

如果dbunit帮助自动禁用外键约束作为其框架的一部分,可能会更好,但是他们不这样做。 他们确实跟踪方言…为什么不使用它们呢? 最终,所有这一切都迫使程序员浪费时间,而不是迅速起床和testing。

3)XML是一个写作的痛苦。 我不必多说这个。 他们还提供了很多方法来做到这一点,我认为这只是使问题复杂化。 只要提供一个真正坚实的方法,并完成它。

4)当你的数据变大时,跟踪ID和他们一致/正确的关系是一个皇家的痛苦。

另外,如果你不在一个月的项目上工作,你怎么记得user_id 1是一个pipe理员,user_id 2是一个商业用户,user_id 3是一个工程师和user_id 4是别的东西? 回去检查这是浪费更多的时间。 应该有一个有意义的方式来检索它以外的任意数字。

5)速度很慢。 我发现,除非使用hsqldb,否则会很痛苦。 它不一定是。 还有很多方法搞砸了它的configuration,因为“开箱即用”并不容易。 有一个驼峰,你必须经过正确的工作。 所有这一切都鼓励人们不要使用它,或者当它们开始使用它的时候被激怒。

6)有些价值倾向于重复,喜欢date。 指定默认值,或者甚至让框架自动设置默认值,即使没有告诉它把默认值放在那里,也不错。 这样你就可以用你想要的值创build对象,并把其余的closures。 如果不需要,这肯定会指定列的每个angular落和裂缝。

7)可能最令人讨厌的是第一个条目必须包含所有的值 – 甚至是空的占位符 – 或者将来的行不会select你实际指定的列。

对于将[NULL]转换为实际的null值,DBunit没有合理的默认值。 你必须手动添加它。 告诉我,谁没有用dbunit做到这一点? 每个人都有。 它不应该是这样的!

这意味着如果你有一个多态的对象,你必须把所有的外键声明为第一行每个子类的连接表,尽pipe它们是空的。 如果你为所有的子types做一个表,你仍然需要指定第一行的所有字段。 这太糟糕了。

为了满足我的需求,还是应该成为更好的数据库testing框架的下一个框架开发人员?

我不知道有任何DbUnit的真正替代品, @Joe提到的工具都不在我的眼中:

  • Incanto :不是DB不可知的
  • SQLUnit :用于testing数据库存储过程的回归和unit testing工具(这不是DbUnit的重点)
  • 仙人掌 :一个容器内testing的工具(我没有看到它对数据库的帮助)
  • Liquibase :一个数据库迁移工具(不加载/validation数据)
  • ORMUnit :可以初始化一个数据库,但仅此而已
  • JMock :根本不与DbUnit竞争

话虽如此,我个人在小型和大型项目上成功地使用过DbUnit,我发现它非常实用,特别是在使用Unitils及其DbUnit模块时。 这并不意味着它是完美的,不能改善,但体面的工具(无论是定制或Unitils),使用它是一个体面的经验。

所以让我回答一下你的观点:

1)不build议使用最简单的写入和上手格式。 他们希望你使用臃肿的格式。 有些甚至需要XML模式。 好吧,无所谓了。

DbUnit支持平面或结构化的XML,XLS,CSV。 你想使用什么革命性的格式? 顺便说一下,使用XML时,DTD或模式不是强制性的。 但它给你一些很好的东西,比如validation和自动完成,那又怎么样? Unitils可以为您轻松生成 ,请参阅生成数据库结构的XSD或DTD 。

如果dbunit帮助自动禁用外键约束作为其框架的一部分,可能会更好,但是他们不这样做。 他们确实跟踪方言…为什么不使用它们呢? 最终,所有这一切都迫使程序员浪费时间,而不是迅速起床和testing。

他们正在等待你的补丁。

同时,Unitils支持透明地处理约束,请参阅禁用约束和更新序列 。

3)XML是一个写作的痛苦。 我不必多说这个。 他们还提供了很多方法来做到这一点,我认为这只是使问题复杂化。 只要提供一个真正坚实的方法,并完成它。

我觉得痛苦是主观的,但我不觉得它很痛苦,尤其是当使用模式和自动完成。 什么是你build议的银弹?

4)当你的数据变大时,跟踪ID和他们一致/正确的关系是一个皇家的痛苦。

让他们小,这是一个知道的最佳做法 。 你违背了已知的最佳做法,然后抱怨…

另外,如果你不在一个月的项目上工作,你怎么记得user_id 1是一个pipe理员,user_id 2是一个商业用户,user_id 3是一个工程师和user_id 4是别的东西? 回去检查这是浪费更多的时间。 应该有一个有意义的方式来检索它以外的任意数字。

是的,任务切换是反生产力的。 但是由于你使用的是低级数据,所以你必须知道它们是如何表示的,除非你使用更高级别的API(当然这不是DbUnit的目的),否则就没有什么神奇的解决scheme。

5)速度很慢。 我发现,除非使用hsqldb,否则会很痛苦。 它不一定是。 还有很多方法搞砸了它的configuration,因为“开箱即用”并不容易。 有一个驼峰,你必须经过正确的工作。 所有这一切都鼓励人们不要使用它,或者当它们开始使用它的时候被激怒。

这是数据库和JDBC固有的,而不是DbUnit。 如果你想让事情尽可能快(如果你有一个更好的不可知的方式来做事情,我会很高兴地了解它)使用像H2这样的快速数据库。

6)也许最烦人的是,第一个条目必须包括所有的值 – 甚至是空占位符 – 或未来的行不会select你实际指定的列。

不像Unitils – Home – JavaPolis 2008或unit testing:unitils&dbmaintain这样的演示文稿中提到使用Unitils 。

为了满足我的需求,还是应该成为更好的数据库testing框架的下一个框架开发人员?

如果您认为自己可以做得更好,也许可以为现有解决scheme做出贡献。 如果这是不可能的,如果你认为你可以创build杀手级的数据库testing框架,我可以说,做到这一点。 但不要忘记,咆哮很容易,想出解决scheme,使用自己的解决scheme是less之又less。

作为一个DbUnit的开发者,我很感激批评,我必须同意你的观点。 我们正在开始下一个DbUnit主要版本的devise,我希望邀请您参与讨论和开发。

我不打算回答你的观点,因为你的问题并不是真正与DbUnit相关,而是与DbUnit的select有关。 无论如何,我只是想强调你的观点7是完全错误的:你不需要再指定第一行的所有列,该特征被称为列感测。 我不打算告诉你为什么它不是默认启用的,因为你确实很聪明,可以自己理解它。

我会给scaladbtest一个深入的检查,希望我们可以整合他们的想法。

面对使用DBUnit的类似问题,我发现这个: http ://dbsetup.ninja-squad.com/index.html可能解决的问题。 比如在单独的文件中表示testing数据,所有的数据库内容都包含在java类本身中。

如果你使用Spring Framework(或者不介意至less用于testing),那么Spring DBUnit是目前我知道和使用的普通DBUnit的最佳(维护)select。 引用他们的网站:

Spring DBUnit提供了Springtesting框架和stream行的DBUnit项目之间的集成。 它允许您使用简单的注释设置和拆卸数据库表,并在testing完成后检查预期的表内容。

Spring DBUnit似乎是DBunit testing的“有点官方”的Spring解决scheme(使用DBUnit); 至less图书馆的作者/维护者Phil Webb正在SpringSource / Pivotal工作。

我使用DBUnit,用几个包装来平滑粗糙的边缘。 一个很好的工具,可以补充或重叠的function是Jailer 。 它可以从参考数据库提取数据的子集,并将其存储为DBUnit兼容的XML文件,或作为“拓扑sorting的DML文件”,这些文件遵守外键约束。

你正在performance出色

过去几年来,我一直在为很多门户网站工作,主要是使用PHP,但是现在也是一些Java。
就像你,我不明白这些年来,框架和unit testing开发人员似乎并没有意识到在过去的十年中存储处理已经发生了什么变化。 发送create / insert / truncate语句到一些数据库是不够的! 如果您正在大规模运营,最终会采用各种各样的存储后端,分层组织,以便快速推出热门内容。 另外在数据库方面还有数据分区的问题。 如果您没有正确的外键抽象,那么当您的存储设置更改时,您肯定会疯狂。 虽然我们在这里:夹具顺序的外键优先有许多陷阱,我还没有看到与DBUnit真正的解决scheme。

无论如何,重要的是只有一个基本的数据库存储单元进行testing对于复杂的存储设置是不够的,因为它们经常不能在现场环境中重现问题,并且是维护的麻烦。

不想听起来像一个变形金刚男孩:一个事情没事的地方是ruby on rails上的ruby on rails 。 人们似乎有一个持续的模式概念,实际上已经有了一些想法。 如果你在使用PHPSymfony就是你要去的地方。 它通过默认的Doctrine包含而受到限制,同样也是以DB为中心的,但界面清晰,扩展性强,完全复制了导轨夹具系统。 在职业上,我需要坚持现在的自制解决scheme,但他们工作正常。

这里有一些我非常喜欢的或者觉得有趣的工具(DBunit除外)。 至less他们可以提供一些启发:

  • Incanto的
  • SQLunit
  • 仙人掌
  • Liquibase
  • ORMUnit
  • JMock的

请注意,就范围或function集而言,这些都不是DBunit的真正竞争对手。 但是,有一些有趣的想法值得一看。 祝你好运!

我们写Daleq作为DbUnit的一个包装来解决一些上面提到的问题。 它允许在你的unit testing中填充一个数据库,而不是依靠编辑XML文件。

我也有类似的问题与DBUnit。 特别是使用它来填充本地开发数据和从真实数据库导出数据。 我遇到了几个情况,它会导出一个数据集,它不能然后导入。

这启发了我为它写一个新的库: https : //github.com/jeffskj/phonydata

这使用groovy DSL来定义数据集,这些数据集使数据非常紧凑,并且使得像生成随机数据这样的很酷的事情成为可能,因为它只是常规代码。

在这里可以find使用Springconfiguration和Specs2testing的替代方法

我刚刚发布了一个Groovy基于DSL的框架,称为可通过github使用的踏板加载器。 文档在这里 。

它允许您直接使用JPA实体级抽象。 由于它是一个groovy脚本,你可以使用所有的groovy结构。

为了将行插入由名为Student的JPA实体支持的表中,使用名为id,name和grade的字段(不是数据库列,但是映射字段),您可以执行如下操作:

 allStudents = table(Student, ['id', 'name', 'grade']) { row 1, 'Joe', Grade.A rowOfInterest = row 2, 'John', Grade.B } 

Grade是映射到数据库列的Student类中的枚举(可能使用JPA 2.1 @Convert注释)。 allStudents是一个将保存行的列表,rowOfInterest是对特定行的引用。 这些属性(allStudents和rowOfInterest)可用于您的unit testing。

DBUnit的情况确实有时令人沮丧。 有些问题可以从Marc Philipp的dbunit-datasetbuilder中解决,特别是如果你把它和validation器结合起来的话,这个问题还处在一个很早的阶段。 你可以在SZE看到它的行动。

免责声明:所有引用的github资源由我维护。

我刚刚发布了一个名为JDBDT(Java数据库增量testing)的库,您可以在软件testing中使用它来进行数据库设置和validation。

看看http://jdbdt.org

最好的,爱德华多