使用 spring、hibernate 和 scala，有没有比 dbunit 更好的方法来加载测试数据？
以下是我非常不喜欢 dbunit 的一些事情：
1) 您无法指定插入的确切顺序，因为 dbunit 喜欢按表名而不是按您在 XML 文件中定义的顺序对插入进行分组。当您的记录依赖于其他表中的其他记录时，这是一个问题，因此您必须在测试期间禁用外键约束...这实际上很糟糕，因为这些外键约束将在生产中被触发，而您的测试不会被触发意识到他们！
2) 他们似乎执意要强迫你使用 xml 命名空间来定义你的 xml...而且我真的懒得这么做。我喜欢没有任何命名空间的 data.xml。有用。但他们坚决反对它。
3) 在每个测试的基础上创建不同的 xml 文件很困难，因此它实际上鼓励为整个应用程序创建数据。不幸的是，一旦数据规模增大并且事情变得纠缠在一起，这个过程也会有点臃肿。必须有一种更好的方法将测试数据分割成块，而不必在所有测试中复制/粘贴大量测试数据。
4) 在一个大的 xml 文件中跟踪 id 引用是不可能的。如果您有 130 个域类，它就会变得令人困惑。这个模型根本无法扩展。
Spring/Hibernate 领域是否有一些不那么臃肿、更好的东西？ db 单元已经不再受欢迎，我真的在寻找更好的东西。
Here are some things I really dislike about dbunit:
1) You cannot specify the exact ordering the inserts because dbunit likes to group your inserts by table name, and not by the order you define them in the XML file. This is a problem when you have records depending on other records in other tables, so you have to disable foreign key constraints during your tests... which actually sucks because these foreign key constraints will get fired in production while your tests won't be aware of them!
2) They seem hellbent on forcing you to use an xml namespace to define your xml... and I honestly can't be bothered to do this. I like the data.xml without any namespace. It works. But they are so hellbent on deprecating it.
3) Creating different xml files is hard on a per test basis, so it actually encourages creating data for your entire app. Unfortunately, this process is a little bloated too once the data grows in size and things get inter tangled. There has got to be a better way to split up your test data into chunks without having to copy/paste a lot of the test data across all of your tests.
4) Keeping track of id references in a big xml file is just impossible. If you have 130 domain classes, it just gets bewildering. This model simply does not scale.
Is there something less bloated and better in the Spring/Hibernate space? db unit has worn out its welcome and I'm really looking for something better.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
1) 看看是否可以将约束定义为可延迟(Oracle docs)，检查将推迟直到事务提交。
对于其他情况，请考虑使用工厂方法，即使用知道如何创建对象并将其插入数据库以进行测试的工厂类。这可能会破坏测试的某些目的，因为您依赖插入/更新代码来使测试正常工作。
我发现工厂方法工作正常，如果你保持它足够简单的话。
For 1) See if you can define your constraints as deferrable (Oracle docs), the check will be deferred until the commit of the transaction.
For the others, consider using a Factory approach, ie, using a Factory class that knows how to create objects and insert them in the DB for testing purposes. This may defeat some of the purpose of testing, since you rely on your insert/update code for the test to work.
I've found that the factory approach works ok, if you keet it simple enough.