我最近参与使用PHPUnit的一些TDD。 我一定要考一个数据库驱动的应用程序，并阅读有关的DbUnit扩展，我正打算研究和在未来几周内实现。
不过，我也碰到过这个演讲由他本人-塞巴斯蒂安伯格曼- ，这在我的越轨行为已经蒙上有些怀疑他有一个名为幻灯片“如果你能避免测试对MySQL的。
有人可以解释为什么我不应该测试对MySQL的原因是什么？
谢谢
Answer 1:
有两个原因：
- 它是缓慢的（和单元测试需要要快）
- 它增加了额外的故障点，超出你的控制（当DB连接失败并测试真的失败 ？）
相反，正如笔者建议你应该内存数据库与测试你的DAL，喜欢SQLite的。 这消除上述问题。
然而，这种方法也有它的缺点太 - 你可能有从一个数据库方言SQLite的移植SQL的问题。 这自然意味着你将无法测试MySQL您DAL的特定部分。 一如往常，这是一把双刃剑 - 你的单元测试的速度和隔离，但你失去信誉（如果我们可以这样调用它） - 如果它在SQLite的过去了，你可以100％肯定它的工作原理上的MySQL？
这可能是并不坏主意离开你的DAL / DAO测试，集成测试阶段，在那里你会测试他们的核心agains使用，离开了单元测试的小东西真正的数据库引擎; 例如映射（如果您使用ORM即是）。
编辑 ： 快速绝不严格的要求-这是一个好的一般建议。 在做TDD的开发人员运行单元测试了很多 （这样的想法，每次提交到本地回购/每一个重要的代码更改都需要通过运行单元测试代码库的完整性检查） -也许不是所有的人，但肯定一些。 你想这个过程要快。
现在，有慢测试通常结尾是这样的：
- “哥们儿，这东西跑这么慢......”
- “也许我可以运行只是少数人的......以后我会跑休息”
- 在这一点上，我们知道以后永远不会到来
- “嘿，我上次提交没有破坏任何东西，我没有运行在所有的任何测试！”
- “为什么我毕竟运行它们？”
写未运行测试，几乎杀死写他们的目的。
这件事情发生在谁与我工作的朋友; 他的团队运行+/- 20分钟 （DAL测试做得不好，参与测试的IoC容器），开发商开始运行一些测试，不一会儿“当前构建断路器”的电子邮件成了日常用品测试套件。 他们有相当大的套房，但破测试不是那么糟糕 。
总体而言，你的做法似乎是正确的 - 我不动测试的SQLite。 就像我建议，有集成测试套件测试（这样可以分别比普通，单元测试套件运行）数据库层。
Answer 2:
我完全被塞巴斯蒂安伯格曼书面轨33的标题不同意。
（因为从幻灯片上的信息可以很容易地被误解，我相信，在他的讲座中，他解释了真正意义）
正如在他的介绍中陈述调试很烂，但测试的岩石 。
如果现实环境中使用MySQL，你必须针对MySQL的测试。 否则，你会发现自己的调试是什么SQLite和MySQL之间的差异。
我相信，他的方向给开发商，而不是单元测试，在这个意义上我也建议开发人员可以保持他们的代码数据库中和成为可能需要的任何努力。 这将提高项目的整体生命周期中，不仅单元测试的质量。 它会保护甚至从MySQL本身的功能改进。 （有过去有很多的问题）。
但在测试单件的代码，使用SQL，无论何时何其他testings你已经做了，则必须对实物进行测试。
我的做法是创建数据库连接，并具有测试，以与该层反应的抽象层。 随后我创建的，我想测试每个数据库服务器不同的具体类。
随着考虑到环境中，我们可以测试frequenlty对SQLite的，但真正的测试将每天至少运行一次。
Answer 3:
我使用DbUnit来测试我的模型（MVC发言，包括ORM的模型），因为它们是密切相关的数据库。 对于一切（主要控制器），我使用Mock对象。
单元测试的基本思路是，以测试只是其中的一个应用程序代码单元（这是一个类）的时间，所以最好避免使用DB除非代码直接使用它。
，当然，性能的问题。 例如，我有500〜测试车型，几乎所有的人都使用DB和灯具。 大约需要30-40秒来执行所有这些测试的蛮快的计算机上。 代码覆盖率报表生成时间约一分钟。
文章来源: Why should I avoid using DbUnit to test MySQL?
