是否有类似 dbunit 的框架对 java/scala 没有吸引力？

Is there a dbunit-like framework that doesn't suck for java/scala?

提问by egervari

I was thinking of making a new, light-weight database population framework. I absolutely hate dbunit. Before I do, I want to know if someone already did it.

我正在考虑制作一个新的、轻量级的数据库填充框架。我绝对讨厌 dbunit。在我做之前，我想知道是否有人已经这样做了。

Things i dislike about dbunit:

我不喜欢 dbunit 的地方：

1) The simplest format to write and get started is deprecated. They want you to use formats that are bloated. Some even require xml schemas. Yeah, whatever.

1) 不推荐使用最简单的编写和入门格式。他们希望您使用臃肿的格式。有些甚至需要 xml 模式。好吧，无所谓了。

2) They populate rows not in the order you write them, but in the order tables are defined in the xml file. This is really bad because you can't order your data in such a way that foreign key constraints won't cause problems. This just forces you to go through the hassle of turning them off altogether.

2）它们填充行不是按照您编写它们的顺序，而是按照在 xml 文件中定义的顺序表。这真的很糟糕，因为您无法以外键约束不会导致问题的方式对数据进行排序。这只会迫使您经历完全关闭它们的麻烦。

This also wastes time and bloats up your junit base classes to include code to disable the foreign key constraints. You will probably have to test for the database type (hsqldb, etc.) and disable them in database-specific ways. This is way bad.

这也会浪费时间并使您的 junit 基类膨胀以包含禁用外键约束的代码。您可能必须测试数据库类型（hsqldb 等）并以特定于数据库的方式禁用它们。这太糟糕了。

It could be better if dbunit helped in disabling foreign key constraints as part of their framework automatically, but they don't do this. They do keep track of dialects... so why not use them for this? Ultimately, all of this does is force the programmer to waste time and not get up and testing quickly.

如果 dbunit 帮助自动禁用外键约束作为其框架的一部分，那可能会更好，但他们不这样做。他们确实会跟踪方言......那么为什么不使用它们呢？最终，所有这些都迫使程序员浪费时间而不是快速起床进行测试。

3) XML is a pain to write. I don't need to say more about this. They also offer so many ways to do it, that I think it just complicates matters. Just offer one really solid way and be done with it.

3) XML 写起来很痛苦。关于这一点我不需要多说。他们还提供了很多方法来做到这一点，我认为这只会使事情复杂化。只需提供一种非常可靠的方法并完成它。

4) When your data gets large, keeping track of the ids and their consistent/correct relationships is a royal pain.

4) 当您的数据变大时，跟踪 id 及其一致/正确的关系是一种极大的痛苦。

Also, if you don't work on a project for a month, how are you to remember that user_id 1 was an admin, user_id 2 was a business user, user_id 3 was an engineer and user_id 4 was something else? Going back to check this is wasting more time. There should be a meaningful way to retrieve it other than an arbitrary number.

另外，如果你一个月不做项目，你怎么记得 user_id 1 是管理员，user_id 2 是商业用户，user_id 3 是工程师，而 user_id 4 是别的什么？回去检查这会浪费更多时间。除了任意数字之外，应该有一种有意义的方式来检索它。

5) It's slow. I've found that unless hsqldb is used, it is painfully slow. It doesn't have to be. There are also numerous ways to mess up its configuration as it is not easy to do "out of the box". There is a hump that you must go through to get it working right. All this does is encourage people to not use it, or be pissed of when they do start to use it.

5）它很慢。我发现除非使用 hsqldb，否则它会非常缓慢。不必如此。还有很多方法可以弄乱其配置，因为“开箱即用”并不容易。您必须经历一个障碍才能使其正常工作。所有这些都是鼓励人们不要使用它，或者在他们开始使用它时感到生气。

6) Some values tend to repeat a lot, likes dates. It'd be nice to specify defaults, or even have the framework put defaults in automatically, even without you telling it to put defaults in there. That way you can create objects just with the values you want, and leave the rest off. This sure beats specifying every nook and cranny of a column if it's not required.

6）有些值往往会重复很多，比如日期。最好指定默认值，甚至让框架自动放置默认值，即使您没有告诉它在那里放置默认值。这样你就可以只用你想要的值来创建对象，其余的就不用了。如果不需要，这肯定会胜过指定列的每个角落和缝隙。

7) Probably the most annoying thing is that the first entry must include ALL the values - even null placeholders - or future rows won't pick the columns that you actually specified.

7) 可能最烦人的事情是第一个条目必须包含所有值 - 甚至空占位符 - 否则未来的行将不会选择您实际指定的列。

DBunit doesn't have a sensible default for translating [NULL] to a real null value either. You have to manually add it. Tell me, who hasn't done this with dbunit? Everyone has. It shouldn't be like this!

DBunit 也没有将 [NULL] 转换为真正的空值的合理默认值。您必须手动添加它。告诉我，谁没有用 dbunit 做过这件事？每个人都有。不应该是这样的！

What this means is that if you have a polymorphic object, you must declare all the foreign keys to the joining tables of each subclass in the first row, even though they are null. If you do a table for all subclasses pattern, you still have to specify all the fields on the first row. This is just awful.

这意味着如果你有一个多态对象，你必须在第一行中声明每个子类的连接表的所有外键，即使它们是空的。如果你为所有子类模式做一个表格，你仍然必须在第一行指定所有字段。这太可怕了。

Anything out there to satisfy me, or should I become the next framework developer of a much better database testing framework?

有什么可以满足我的，还是我应该成为更好的数据库测试框架的下一个框架开发人员？

采纳答案by Pascal Thivent

I'm not aware of any real alternative to DbUnit and none of the tools mentioned by @Joeare in my eyes:

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

• Incanto: not DB agnostic
• SQLUnit: a regression and unit testing harness for testing database stored procedures (that's not what DbUnit is about)
• Cactus: a tool for In-container testing (I fail to see where it helps with databases)
• Liquibase: a database migration tool (doesn't load/verify data)
• ORMUnit: can initialize a database but that's all
• JMock: doesn't compete with DbUnit at all

• Incanto：与数据库无关
• SQLUnit：用于测试数据库存储过程的回归和单元测试工具（这不是 DbUnit 的内容）
• Cactus：容器内测试工具（我看不出它对数据库有什么帮助）
• Liquibase：数据库迁移工具（不加载/验证数据）
• ORMUnit：可以初始化一个数据库，但仅此而已
• JMock：根本不与 DbUnit 竞争

That being said, I've personally used DbUnit successfully several times, on small and huge projects, and I find it pretty usable, especially when using Unitilsand its DbUnit module. This doesn't mean it's perfect and can't be improved but with decent tooling (either custom made or something like Unitils), using it has been a decent experience.

话虽如此，我个人已经在小型和大型项目中多次成功使用 DbUnit，我发现它非常有用，尤其是在使用Unitils及其 DbUnit 模块时。这并不意味着它是完美的并且无法改进，但是有了不错的工具（定制的或类似 Unitils 的工具），使用它是一种不错的体验。

So let me answer some of your points:

所以让我回答你的一些观点：

1) The simplest format to write and get started is deprecated. They want you to use formats that are bloated. Some even require xml schemas. Yeah, whatever.

1) 不推荐使用最简单的编写和入门格式。他们希望您使用臃肿的格式。有些甚至需要 xml 模式。好吧，无所谓了。

DbUnit supports flat or structured XML, XLS, CSV. What revolutionary format would you like to use? By the way, a DTD or schema is not mandatory when using XML. But it gives you nice things like validation and auto-completion, how is that bad? And Unitils can generate it easily for you, see Generate an XSD or DTD of the database structure.

DbUnit 支持平面或结构化的 XML、XLS、CSV。您想使用什么革命性的格式？顺便说一下，在使用 XML 时，DTD 或模式不是必需的。但是它为您提供了诸如验证和自动完成之类的好东西，这有什么坏处？并且 Unitils 可以为您轻松生成它，请参阅生成数据库结构的 XSD 或 DTD。

It could be better if dbunit helped in disabling foreign key constraints as part of their framework automatically, but they don't do this. They do keep track of dialects... so why not use them for this? Ultimately, all of this does is force the programmer to waste time and not get up and testing quickly.

如果 dbunit 帮助自动禁用外键约束作为其框架的一部分，那可能会更好，但他们不这样做。他们确实会跟踪方言......那么为什么不使用它们呢？最终，所有这些都迫使程序员浪费时间而不是快速起床进行测试。

They are waiting for your patch.

他们正在等待您的补丁。

Meanwhile, Unitils provides support to handle constraints transparently, see Disabling constraints and updating sequences.

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

3) XML is a pain to write. I don't need to say more about this. They also offer so many ways to do it, that I think it just complicates matters. Just offer one really solid way and be done with it.

3) XML 写起来很痛苦。关于这一点我不需要多说。他们还提供了很多方法来做到这一点，我认为这只会使事情复杂化。只需提供一种非常可靠的方法并完成它。

I guess pain is subjective but I don't find it painful, especially when using a schema and autocompletion. What is the silver bullet you're suggesting?

我想痛苦是主观的，但我不觉得它痛苦，尤其是在使用模式和自动完成时。你建议的银弹是什么？

4) When your data gets large, keeping track of the ids and their consistent/correct relationships is a royal pain.

4) 当您的数据变大时，跟踪 id 及其一致/正确的关系是一种极大的痛苦。

Keep them small, that's a know best practice. You're going against a known best practice and then complain...

保持它们小，这是一个已知的最佳实践。你违背了一个已知的最佳实践，然后抱怨......

Also, if you don't work on a project for a month, how are you to remember that user_id 1 was an admin, user_id 2 was a business user, user_id 3 was an engineer and user_id 4 was something else? Going back to check this is wasting more time. There should be a meaningful way to retrieve it other than an arbitrary number.

另外，如果你一个月不做项目，你怎么记得 user_id 1 是管理员，user_id 2 是商业用户，user_id 3 是工程师，而 user_id 4 是别的什么？回去检查这会浪费更多时间。除了任意数字之外，应该有一种有意义的方式来检索它。

Yes, task switching is counter productive. But since you're working with low level data, you have to know how they are represented, there is no magic solution unless you use a higher level API of course (but that's not the purpose of DbUnit).

是的，任务切换会适得其反。但是由于您正在处理低级数据，因此您必须知道它们是如何表示的，当然除非您使用更高级别的 API（但这不是 DbUnit 的目的），否则没有神奇的解决方案。

5) It's slow. I've found that unless hsqldb is used, it is painfully slow. It doesn't have to be. There are also numerous ways to mess up its configuration as it is not easy to do "out of the box". There is a hump that you must go through to get it working right. All this does is encourage people to not use it, or be pissed of when they do start to use it.

5）它很慢。我发现除非使用 hsqldb，否则它会非常缓慢。不必如此。还有很多方法可以弄乱其配置，因为“开箱即用”并不容易。您必须经历一个障碍才能使其正常工作。所有这些都是鼓励人们不要使用它，或者在他们开始使用它时感到生气。

That's inherent to databases and JDBC, not DbUnit. Use a fast database like H2 if you want things to be as fast as possible (if you have a better agnostic way to do things, I'd be glad to learn about it).

这是数据库和 JDBC 固有的，而不是 DbUnit。如果您希望事情尽可能快，请使用像 H2 这样的快速数据库（如果您有更好的不可知方式来做事，我很乐意了解它）。

6) Probably the most annoying thing is that the first entry must include ALL the values - even null placeholders - or future rows won't pick the columns that you actually specified.

6）可能最烦人的事情是第一个条目必须包含所有值 - 甚至空占位符 - 否则未来的行将不会选择您实际指定的列。

Not when using Unitils as mentioned in presentations like Unitils - Home - JavaPolis 2008or Unit testing: unitils & dbmaintain.

不是在使用 Unitils - Home - JavaPolis 2008或Unit testing: unitils & dbmaintain 等演讲中提到的。

Anything out there to satisfy me, or should I become the next framework developer of a much better database testing framework?

有什么可以满足我的，还是我应该成为更好的数据库测试框架的下一个框架开发人员？

If you think you can make things better, maybe contribute to existing solutions. If that's not possible and if you think you can create the killer database testing framework, what can I say, do it. But don't forget, ranting is easy, coming up with solutions using your own solutions is less so.

如果你认为你可以让事情变得更好，也许可以为现有的解决方案做出贡献。如果这是不可能的，并且如果您认为您可以创建杀手级数据库测试框架，我能说什么，就去做吧。但是不要忘记，咆哮很容易，使用您自己的解决方案提出解决方案则不然。

回答by Joseph Weissman

Here's a short list of a few tools in this vein (besides DBunit) that I particularly like, or find interesting. At the very least they may offer some inspiration:

这是我特别喜欢或感兴趣的一些与此相关的工具（除了 DBunit）的简短列表。至少他们可以提供一些灵感：

• Incanto
• SQLunit
• Cactus
• Liquibase
• ORMUnit
• JMock

• 咒语
• SQL单元
• 仙人掌
• Liquibase
• ORM单元
• 模拟

Note that none of these are really competitors to DBunit in terms of scope or feature sets. However, there are some interesting ideas there that might be worth taking a look at. Good luck!

请注意，就范围或功能集而言，这些都不是 DBunit 的真正竞争对手。但是，那里有一些有趣的想法可能值得一看。祝你好运！

回答by retronym

I use DBUnit, with a few wrappers to smooth over the rough edges. A nice tool that can either complement or overlap the functionality is Jailer. It can extract subsets of data from a reference database, and store this as either DBUnit compatible XML files, or as "topologically sorted DML files", which respect the foreign key constraints.

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

回答by Roberto Lo Giacco

As a DbUnit developer I'm grateful for criticism and I must partially agree with you. We are currently starting the design of the next DbUnit major release and I wish to invite you to participate both in the discussion and development.

作为一名 DbUnit 开发人员，我很感激批评，我必须部分同意你的看法。我们目前正在开始设计下一个 DbUnit 主要版本，我希望邀请您参与讨论和开发。

I'm not going to answer your points as your question is not really related to DbUnit, but to DbUnit alternatives. Anyway, I just want to highlight your point 7 is completely false: you do not need to specify all the columns on first row any more, the feature is called column sensing. I'm not going to tell you why it's not enabled by default as you are surely smart enough to understand it by yourself.

我不会回答你的观点，因为你的问题与 DbUnit 并没有真正的关系，而是与 DbUnit 替代品有关。无论如何，我只想强调您的第 7 点是完全错误的：您不需要再指定第一行的所有列，该功能称为列感应。我不会告诉你为什么默认情况下它没有启用，因为你肯定足够聪明，可以自己理解它。

I'll give scaladbtest a deep examination in the hope we can integrate their ideas.

我会对scaladbtest 进行深入的考察，希望我们能够整合他们的想法。

回答by carrion

You're making excellent point.

你说得很好。

I've been working for a lot of web portals over the last years, mostly with PHP, but also some Java now and then.
And like you I don't get that after all these years framework and unittesting developers don't seem to realize how much storage handling has changed in the last decade. It's not enough to just send create/insert/truncate statements to some database! If you're operating at large scale you end up employing all sorts of storage backends, organized in layers to push hot content out fast. Plus on the Database front there's the issue of data partitioning. If you don't have a proper foreign key abstraction provided you will certainly go nuts when your storage setup changes. And while we're at it: fixture ordering by foreign key precedence has many pitfalls and I have yet to see a real solution for that with DBUnit.

在过去的几年里，我一直在为许多 Web 门户工作，主要使用 PHP，但偶尔也会使用一些 Java。
和你一样，我不明白这些年来框架和单元测试开发人员似乎没有意识到在过去十年中存储处理发生了多少变化。仅仅将创建/插入/截断语句发送到某个数据库是不够的！如果您大规模运营，您最终会使用各种存储后端，分层组织以快速推出热门内容。此外，在数据库方面还有数据分区的问题。如果您没有适当的外键抽象，那么当您的存储设置发生变化时，您肯定会发疯。当我们在做的时候：DBUnit.

Anyway, the point is having just a basic database storage in place for unittesting is not enough for complex storage setups, since they often fail to reproduce problems in the live environment and are a pain in the ass to maintain.

无论如何，关键是只有一个基本的数据库存储用于单元测试对于复杂的存储设置是不够的，因为它们通常无法在实时环境中重现问题并且维护起来很麻烦。

Without wanting to sound like a fanboy: one place where things are okay is ruby on rails. That has a persistent model concept that people seem to have actually put some thought into. If you're dealing in PHP, Symfonyis the place to go. It is limited via the default inclusion of Doctrine, with is also quite DB-centric, but it has clean interfaces and great extensibility and copied the rails fixture system completely. Professionally I need to stick to homebrew solutions for now, but they work okay.

不想听起来像个狂热分子：事情还可以的一个地方是ruby on rails。它有一个持久的模型概念，人们似乎已经对此进行了一些思考。如果你在交易PHP，Symfony是去的地方。它受到默认包含的Doctrine, with 也很以 DB 为中心的限制，但它具有干净的界面和强大的可扩展性，并且完全复制了 rails 夹具系统。从专业上讲，我现在需要坚持自制解决方案，但它们工作正常。

回答by Lars

We are writing Daleqas a wrapper around DbUnit to address some of the mentioned concerns. It allows populating a DB just within your unit test rather than relying on editing XML files.

我们正在编写Daleq作为 DbUnit 的包装器来解决一些提到的问题。它允许仅在单元测试中填充数据库，而不是依赖于编辑 XML 文件。

回答by blue-sky

Faced with similar concerns using DBUnit I have found this : http://dbsetup.ninja-squad.com/index.htmlwhich may address concerns. Such as instead of representing test data in separate files all DB content is contained within the java class itself.

面对使用 DBUnit 的类似问题，我发现了这个：http://dbsetup.ninja-squad.com/index.html可以解决问题。例如，所有 DB 内容都包含在 java 类本身中，而不是在单独的文件中表示测试数据。

回答by pagoda_5b

An alternative using Springconfiguration and Specs2testing can be found here

可以在此处找到使用Spring配置和Specs2测试的替代方法

回答by Jeff S

I too had similar issues with DBUnit. Especially for using it to populate local development data and exporting data from a real database. I ran into several cases where it would export a dataset that it couldn't then import.

我也有 DBUnit 的类似问题。特别是使用它来填充本地开发数据和从真实数据库中导出数据。我遇到了几种情况，它会导出无法导入的数据集。

This inspired me to write a new library for it: https://github.com/jeffskj/phonydata

这激发了我为它编写一个新库：https: //github.com/jeffskj/phonydata

This uses a groovy DSL to define the datasets which makes for a very compact representation of the data and makes it possible to do cool things like generate random data since it's just groovy code.

这使用了一个 groovy DSL 来定义数据集，这使得数据的表示非常紧凑，并且可以做很酷的事情，比如生成随机数据，因为它只是 groovy 代码。

回答by Chriki

If you use the Spring Framework (or don't mind using it at least for testing), then Spring DBUnitis currently the best (maintained) alternative to plain DBUnit that I know and use. Quoting their website:

如果您使用 Spring Framework（或者至少不介意使用它进行测试），那么Spring DBUnit目前是我所知道和使用的普通 DBUnit 的最佳（维护）替代方案。引用他们的网站：

Spring DBUnit provides integration between the Spring testing framework and the popular DBUnit project. It allows you to setup and teardown database tables using simple annotations as well as checking expected table contents once a test completes.

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

Spring DBUnit appears to be the ‘somewhat official' Spring solution for DB unit testing (with DBUnit); at least the author/maintainer of the library, Phil Webb, is working at SpringSource/Pivotal.

Spring DBUnit 似乎是 DB 单元测试（使用 DBUnit）的“有点官方”的 Spring 解决方案；至少该库的作者/维护者 Phil Webb 正在 SpringSource/Pivotal 工作。