.NET - 对数据库中的代码和状态进行单元测试答案

【问题标题】：.NET - Unit Testing Your Code and State in Your Database.NET - 对数据库中的代码和状态进行单元测试
【发布时间】：2009-01-29 18:47:27
【问题描述】：

假设：我们针对 SQL Server 2005 使用 .NET 编码

我只是想知道大多数人如何将状态合并到影响其数据库的单元测试中？我知道何时何地使用模拟，但是当你想超越它并实际进行一些数据库测试时......你使用什么策略来设置和拆除你的数据库？你每次测试都这样做吗？或在数据库中设置某个场景并针对该“世界状态”运行多个测试。任何建议都会有所帮助。谢谢。

【问题讨论】：

看过mbUnit吗？它具有您正在谈论的一些功能

标签： .net sql-server unit-testing database-design state

【解决方案1】：

我针对空数据库运行大部分测试用例，这意味着只存在数据库模式，但没有数据。实际数据由测试用例或设置和拆卸根据需要创建和删除。这比准备好数据库需要更长的时间，但更能抵抗数据库架构更改。

【讨论】：

我喜欢这个主意。它还将捕获代码中的错误，这些错误无法处理表格为空的情况，这似乎出现在已经存在了一段时间的遗留系统中。
+1 - 测试那些空表。这基本上是我现在使用的模型。对我来说没问题。

【解决方案2】：

首先，我所有的数据库 DDL“脚本”都是用 C# 类编写的。我使用 Migrator.NET 来执行此操作：我有几个类，其中每个类都包含一些升级或降级数据库的逻辑。

我有一个名为“projectname_test”的数据库，用于针对需要访问数据库的需求运行单元测试。我的 Migrator.NET 类正在升级这个数据库。此数据库由 CI 进程 (CC.NET) 升级。

访问该数据库的单元测试将在运行后删除该数据库中的所有内容。而且，当我想彻底玩它时，我可以简单地删除我的测试数据库；它将由 CC.NET 进程重建。 :)

【讨论】：

其实我已经看到已经更新或者计划了一些重要的新功能，但是我下载后没有看。我自己编写了一些扩展来满足我的需要。
+1 - 我不知道 Migrator.NET。您对项目状态了解多少？我看到它自 2008 年 8 月 5 日起已更新
看起来很容易扩展。我希望这个项目顺利，因为我对 M / Oslo 模型还没有多少信心。

【解决方案3】：

这就是我在 NUnit 中所做的...在标有 [Setup] 属性的方法中启动数据库事务。根据需要设置数据库状态。 NUnit 然后针对该状态运行测试。在一个标有 [TearDown] 属性的方法中回滚数据库事务。你永远不会那样改变数据库的状态。

【讨论】：

它有效，但扩展性非常大。如果您的测试方法已经打开了事务或打开了它们自己的数据库连接，那么您的测试就会死锁。最坏的情况是当你因为死锁而不得不终止你的测试进程并且它在数据库上留下一个未关闭的事务时。哎哟。
我了解扩展，但我之前没有想过以这种方式使用事务。 +1
@Princess：我可以看到多个打开的连接......但是关于嵌套事务的 MSDN 文章说它们应该可以工作。我同意最坏的情况很糟糕......但它是一个测试数据库......我绝对不会在生产服务器上这样做。

【解决方案4】：

看看这个问题和答案 How do I test database-related code with NUnit?

【讨论】：

MbUnit 有类似 NUnit RollBack 属性的东西。就我个人而言，我喜欢自己管理交易的更细粒度的控制。

【解决方案5】：

如果您使用 NHibernate 作为 ORM，则可以轻松地将真正的 SQL Server 数据库（app.config 中的几行）与内存中的 SQLite 数据库交换，该数据库在每次测试时都可以轻松重新创建。这样，您将执行单元测试的集成/构建服务器不再需要访问 SQL Server。

【讨论】：

【解决方案6】：

在大多数产品中，无论是大型托管网站还是带有数据库的收缩包装产品，您通常有 2 个场景需要进行单元测试（我理解这对某些人来说可能不仅仅是单元测试）

全新安装路径 - 当您从头开始创建数据库时
- 使用 MsBuild 和 SQLCMD 自动创建 DB，传入参数
- 将 PowerShell 用于任何服务器级管理工作
升级路径 - 当您升级现有客户的数据库时
- 将已清理的 Real World DB 的备份还原为您的基线
- 如果必须在升级后应用升级
- 再次使用 PowerShell、MsBuild、SQLCMD 来编排工具

对我来说，即使在进行单元测试时，我也喜欢使用“真实世界”数据进行测试，尤其是真实世界的数据量，以便尽早发现接近实施阶段的问题。所以总的来说，我什至不做模拟测试，而是去寻找一个更好的单元测试工具，它可以按需重建和运行。基本上是持续集成方法，或部分 CI（矛盾修饰法）方法。

请注意，如果您采用持续集成方法，即使在实施和开发过程中，您也要牢记的是可交付成果/发布到生产中的部署自动化。基本上从一开始就牢记End，因为如果您的新功能不容易部署，那么它就毫无价值。当今天的大数据水平可扩展性通常意味着您将客户分隔在不同的数据库中并且必须以可预测的方式在其中几个数据库上重复运行部署脚本时，尤其如此。

开发者有多少次声明他们“完成”，但是您甚至不知道如何开始对其进行功能测试，因为它无法部署到除此之外的任何地方开发者环境。

因此，您正在创建的单元测试工具不仅可以真正测试您的代码，还可以测试部署脚本。一般来说，为了实现这一点，我使用 Jenkins、MsBuild、PowerShell。如果涉及浏览器，我会使用 VirtualBox 为 VM 启动不同的浏览器。

【讨论】：