我在考虑创建一个新的、轻量级的数据库总体框架.我绝对讨厌dbunit.在我这么做之前，我想知道是否有人已经这么做了.
关于dbunit我不喜欢的事情:
1)不推荐使用编写和入门最简单的格式.他们希望您使用臃肿的格式.有些甚至需要XML模式.是啊，管他呢.
2)它们填充行的顺序不是按照您编写的顺序，而是按照表在XML文件中定义的顺序.这真的很糟糕，因为您不能以外键约束不会导致问题的方式对数据进行排序.这只会迫使您经历彻底关闭它们的麻烦.
这还会浪费时间，并使您的junit基类inflating ，使其包含禁用外键约束的代码.您可能需要测试数据库类型(hsqldb等).并以特定于数据库的方式禁用它们.这太糟糕了.
如果dbunit帮助将外键约束作为其框架的一部分自动禁用，那会更好，但它们不会这样做.他们确实记录了方言.那么为什么不把它们用来做这个呢？最终，所有这些都会迫使程序员浪费时间，不能快速启动和测试.
3)XML编写起来很麻烦.关于这件事我不需要多说.他们还提供了如此多的方法来做这件事，我认为这只会让事情变得复杂.只要提供一个非常可靠的方法就可以了.
4)当您的数据变得很大时，跟踪ID及其一致/正确的关系是一件非常痛苦的事情.
此外，如果您在一个月内没有处理某个项目，如何才能记住user_id1是管理员，user_id2是业务用户，user_id3是工程师，而user_id4是其他东西呢？回go 判断这是在浪费更多的时间.应该有一种有意义的方式来检索它，而不是任意的数字.
它很慢.我发现，除非使用hsqldb，否则它非常慢.不一定非得这样.由于"开箱即用"并不容易，因此也有很多方法来搞乱它的配置.要让它正常工作，你必须经历一个坎坷.所有这些都是鼓励人们不要使用它，或者当他们真的开始使用它时被激怒.
6)有些值往往会重复很多，比如日期.最好指定默认值，甚至让框架自动放入默认值，即使您不告诉它放入默认值也是如此.这样，您就可以只使用所需的值创建对象，而不使用睡觉.如果不需要，这肯定比指定列的每一个角落和缝隙要好.
7) 可能最烦人的是，第一个条目必须包含所有的值——即使是空占位符——否则future 的行将不会 Select 您实际指定的列.
DBunit也没有将[NULL]转换为真正的NULL值的合理缺省值.您必须手动添加.告诉我，谁没有用dbunit这样做过？每个人都有.事情不应该是这样的！
这意味着如果您有一个多态对象，则必须声明第一行每个子类的连接表的所有外键，即使它们为空.如果您为所有子类模式创建了一个表，则仍然需要指定第一行上的所有字段.这太可怕了.
有什么能让我满意的吗，或者我应该成为下一个更好的数据库测试框架的框架开发者吗？