dbunit mysql_单元测试 – 为什么我应该避免使用DbUnit来测试MySQL？

两个原因：

>它很慢(单元测试需要很快)

>它增加了超出您控制范围的额外故障点(当数据库连接失败时,测试是否真的失败了？)

相反,正如作者建议你应该在内存数据库中测试你的DAL,比如SQLite.这消除了上述问题.

但是,这种方法也有其缺点 – 您可能在将SQL从一个数据库方言移植到SQLite时遇到问题.这自然意味着您将无法测试DAL的MySQL特定部分.一如既往,它是双刃剑 – 你获得单位测试速度和隔离,但你失去了可信度(如果我们可以这样称呼它) – 如果它传递给SQLite,你能100％确定它适用于MySQL吗？

将DAL / DAO测试的核心保留在集成测试阶段可能并不是一个坏主意,在这个阶段,您将再次测试它们使用的真实数据库引擎,并为单元测试留下小东西;例如映射(如果你使用ORM).

编辑：快速绝不是严格的要求 – 这只是一个很好的一般建议.在进行TDD时,您的开发人员将经常运行单元测试(以这种方式思考;每次提交本地存储/每次重要的代码更改都需要通过运行单元测试来检查代码库完整性) – 也许不是全部,但肯定有些.您希望此过程快速.

现在,慢速测试通常会这样结束：

>“伙计,这件事情很慢……”

>“也许我只能运行其中几个…我会稍后休息”

>此时我们知道以后永远不会来

>“嘿,我的最后一次提交没有破坏任何东西,我根本没有进行任何测试！”

>“毕竟我为什么要跑他们？”

编写未运行的测试,几乎杀死了编写它们的目的.

This thing happened to a friend who works with me; his team had test suite running +/- 20 minutes (DAL tests done poorly, IoC container involved in tests), developers started running some tests, and pretty soon the “Current build breakers” emails became daily thing. They had rather large suite, but breaking test was not that bad.

总的来说,你的方法似乎是正确的 – 我不会将测试移到SQLite.像我建议的那样,使用集成测试套件测试数据库层(这样它可以比常规的单元测试套件单独运行).