为什么要避免使用DbUnit测试MySQL? [英] Why should I avoid using DbUnit to test MySQL?

问题描述

我最近开始使用PHPUnit参与一些TDD. 我必须测试一个数据库驱动的应用程序，并了解有关DbUnit扩展的信息，我计划在未来几周内研究和实现该扩展.

但是，我遇到了这个人的演示文稿他自己-塞巴斯蒂安·伯格曼(Sebastian Bergmann)-他有一张名为如果可能的话，请避免对MySQL进行测试"的幻灯片，这使我有些疑惑.

有人可以解释为什么我不应该针对MySQL进行测试的原因吗?

谢谢

解决方案

两个原因:

• 它很慢(并且单元测试必须很快)
• 它会添加超出您控制范围的额外故障点(在数据库连接失败时是否真的测试 fail ?)

相反，正如作者建议的那样，您应该使用内存数据库(例如SQLite)测试DAL.这样可以消除上面提到的问题.

但是，这种方法也有其缺点-您可能在将SQL从一种数据库方言移植到SQLite时遇到问题.这自然意味着您将无法测试DAL的MySQL特定部分.和往常一样，它是一把双刃剑-您可以获得单元测试的速度和隔离度，但是却失去了可信度(如果我们可以这样称呼)-如果它在SQLite上传递了，您能否百分百确定它可以在MySQL上运行? >

将DAL/DAO测试的核心置于集成测试阶段可能不是一个坏主意，在该阶段，您将使用自己使用的真正的DB引擎再次对其进行测试，并为单元测试留一些余地.例如映射(如果您使用的是ORM).

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

现在，进行缓慢的测试通常会像这样结束:

• 伙计，这件事运行得太慢了……"
• 也许我只可以运行其中的一部分...稍后再休息"
• 这时我们知道以后永远不会来
• 嘿，我的上一次提交没有破坏任何东西，我根本没有进行任何测试！"
• 为什么我还要运行它们?"

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

_{这件事发生在和我一起工作的朋友身上；他的团队的测试套件运行+/- 20分钟(DAL测试做得不好，IoC容器参与了测试)，开发人员开始运行 some 测试，不久之后，当前建立破坏者"电子邮件已成为日常工作.他们有相当大的套件，但是破坏测试不是那么糟糕.}

总体而言，您的方法似乎正确-我不会将测试移至SQLite.就像我建议的那样，已经使用集成测试套件对数据库层进行了测试(以便它可以与常规的单元测试套件分开运行).

I have recently become involved with some TDD using PHPUnit. I have to test a database-driven app, and read about the DbUnit extension, which I was planning to research and implement over the coming weeks.

However, I have come across this presentation by the man himself - Sebastian Bergmann - He has a slide entitled 'Avoid testing against MySQL if you can', which has cast some doubts upon my escapade.

Can someone explain the reasons why I should not test against MySQL?

Thanks

解决方案

Two reasons:

• it is slow (and unit tests need to be fast)
• it adds extra failure point that is beyond your control (does test really fail when DB connection fails?)

Instead, as author suggest you should test your DAL with in memory databases, like SQLite. This eliminates problems noted above.

However, this approach has its drawbacks too - you might have problems porting SQL from one database dialect to SQLite. This naturally means you won't be able to test MySQL specific parts of your DAL. As always, it is double edged sword - you get unit test speed and isolation, but you lose credibility (if we can call it this way) - if it passed on SQLite, can you be 100% sure it works on MySQL?

It might be not that bad idea to leave the core of your DAL/DAO tests to integration testing phase, where you will test them agains real DB engine you use and leave small things for unit testing; for example mappings (if you use ORM that is).

Edit: the fast is by no means strict requirement - it's just good general advice. When doing TDD your developers will run unit tests a lot (think this way; every commit to local repo/every important code change will require code base integrity check by running unit tests) - perhaps not all of them, but surely some. You want this process to be quick.

Now, having slow tests usually ends like this:

• "Man, this things runs so slow..."
• "Perhaps I can run just few of them... I'll run rest later"
• At this point we know later never comes
• "Hey, my last commit didn't break anything and I didn't run any tests at all!"
• "Why would I run them after all?"

Writing tests that are not run, pretty much kills the purpose of writing them.

_{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.}

Overall, your approach seems correct - I wouldn't move tests to SQLite. Like I suggested, have database layer tested with integration tests suite (so that it can be run separately than regular, unit tests suite).

这篇关于为什么要避免使用DbUnit测试MySQL?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！