PHPUnit自己的手册some as-yet-unwritten sections标题为“操作”和“数据库测试最佳实践”。
使用PHPUnit测试数据库的最佳做法是什么，特别是MySQL？
答案 0 :(得分：9)
当我使用PHPUnit进行数据库测试时，我在第一个套件的开头加载我的MySQL转储，其中包含我假设在所有测试中都是真的任何信息。每次测试开始时我都使用setupDatabase方法。此方法从我知道已更改的表中删除所有行，然后加载包含我需要保持为true的数据的平面XML数据集。完成此操作后，我运行我正在测试的任何代码。最后，我使用一组简单的方法从数据库中选择行来断言我所做的更改是否正确完成。
我不会说这是一种最佳做法，但对我来说效果很好。我遇到的唯一问题是每次架构更改时都必须对XML数据集进行查找和替换，并且由于所有删除和插入而导致测试运行缓慢。
Zend Framework有一个有趣的PHPUnit库，允许对compare a database table进行平面XML数据集的测试，但我还没有机会使用它。
答案 1 :(得分：3)
一些无序的想法：
在每个测试的startUp（）中加载到db中的夹具（有或没有db结构）是很好的。它可以来，即。来自JSON或XML文件，每个表一个。 如果您将它与getNthFixture（$ sTable，$ nIndex）或countFixtures（$ sTable）等函数结合使用，则可以轻松测试查询。更进一步，您可以使用[LINQ] [1]从数组中获得预期结果，而数据库和数据之间几乎没有差别。灯具查询。我发现在早期的原型设计/开发阶段很容易适应，因为db结构经常发生变化。添加断言以直接比较LINQ查询结果和db查询结果使创建测试纯粹愉快;）
另一个提示：db应该在每个测试方法之前重新初始化，而不是在测试用例之前。理想情况下，您应该放下底座并从完整的灯具组重建它。
并且，如果可以的话，尝试进行适用于不同数据库的测试（有些东西，当然不是可移植的，但大多数是）。至少使用mysql / postgres / other_big_rdbm的sqlite。
如果您正在测试框架或其他复杂系统，您应该模拟数据库访问单例。如果一些硬编码的东西埋藏在不那么灵活的东西中，那么颈部就会感到疼痛。
好主意是记录未通过测试的所有查询，和/或在失败消息中显示它们。也适用于db错误消息。如果您在考虑性能时测试大型数据库，请尝试同时记录慢速查询。
更神奇，也许更难一点，就是自动测试where / having / join中使用的所有列是否都被编入索引。可能是属于Jointed Php / Database Code Sniffer（tm）而不是单元测试的东西，并且实现起来不是很简单，但一旦使用就会大大保证代码的质量。
另一个好的建议，来自悲伤的个人经历：总是为非常精彩的字符集添加测试，特别是如果你使用许多不同的语言。 ISO-8859-1世界非常小;）
[1]：http://phplinq.codeplex.com/ LINQ