使用 PHPUnit 进行数据库测试的最佳实践 [已关闭]

当我使用PHPUnit进行数据库测试时，我会在第一个套件的开头加载我的MySQL转储，其中包含我假设在所有测试中都正确的任何信息。当每个测试开始时，我使用 setupDatabase 方法。此方法从我知道已更改的表中删除所有行，然后加载一个平面 XML 数据集，其中包含我需要保持为 true 的数据。完成此操作后，我运行正在测试的任何代码。最后，我使用一组简单的方法来从数据库中选择行，以断言我所做的更改已正确完成。

我不会说这是一个最佳实践，但对我来说效果很好。我遇到的唯一问题是，由于所有删除和插入，每次架构更改并且测试运行缓慢时，都必须对XML数据集进行查找和替换。

Zend Framework有一个有趣的PHPUnit库，它允许测试将数据库表与平面XML数据集进行比较，但我还没有机会使用它。

一些无序的想法：

最好在每次测试的startUp（）中将夹具（带或不带db结构）加载到db中。它可以来ie。从 JSON 或 XML 文件，每个表一个。如果你将它与getNthFixture（$sTable，$nIndex）或countfixtures（$sTable）等函数结合使用，你可以很容易地测试你的查询。甚至更进一步，您可以使用 [LINQ][1] 从一组夹具中获取预期结果，而 DB 和 Fixtures 查询之间几乎没有差异。我发现在早期原型设计/开发阶段很容易适应，当时数据库结构经常变化。添加断言以直接比较 LINQ 查询结果与数据库查询结果，使创建测试成为纯粹的乐趣;)

另一个提示：db应该在每个测试方法之前重新初始化，而不是在测试用例之前。理想情况下，您应该放下底座，然后从全套夹具中重建。

而且，如果可以的话，尝试进行适用于不同数据库的测试（当然，有些东西不是可移植的，但大多数都是）。除了 mysql/postgres/other_big_rdbm 之外，至少还要使用 sqlite。

如果您正在测试框架或其他复杂系统，则可能应该模拟数据库访问单例。如果一些硬编码的东西深埋在不那么灵活的orm中，它可能会很痛苦，比如说，脖子。

好主意是记录所有未通过测试的查询，和/或在失败消息中显示它们。也适用于数据库错误消息。如果在性能问题时测试大型数据库，请尝试同时记录慢速查询。

更神奇，也许有点困难，是自动测试是否在何处/具有/连接中使用的所有列都已编制索引。也许是应该属于联合Php /数据库代码嗅探器（tm）而不是单元测试的东西，并且实现起来不是很简单，但是一旦使用就可以大大保证代码的质量。

另一个好建议，来自悲伤的个人经历：总是为非常疯狂的字符集添加测试，特别是如果你使用许多不同的语言。ISO-8859-1世界非常小;)

[1]： http://phplinq.codeplex.com/ LINQ