我正在寻找令人满意的选项来对我的 .NET DAL 类进行单元测试；因为它们是 DAL 类，所以它们直接使用 ADO.NET 访问数据库。目前我使用 MSSQL 数据库的实例进行测试，但想知道有哪些更快的选项——因为单元测试需要尽快运行，内存中的解决方案将是理想的。
我还应该提到我已经将自己绑定到 TSQL，因为我只会使用 Microsoft 平台。
Eric Smith
问问题
9899 次
6 回答
3
鉴于您声明：
我还应该提到我已经将自己绑定到 TSQL，因为我只会使用 Microsoft 平台。
然后使用 SqlServer 精简版可能会很好地满足您的需求。它不会完全在内存中运行，但可以在只读模式下运行（不会对主数据库文件进行编辑，因此可以同时被多个测试使用）
有一些陷阱，不支持存储过程，需要翻译一些数据类型，并且某些数据类型有严格的限制（特别是 varchar，它只能达到 4000 个字符） Linq to Sql 也没有得到适当的支持。
尽管如此，我还是使用 SqlServer Compact Edition 作为适当的 Sql Server 数据库的几乎完全替代品，效果很好。
于 2009-01-27T11:22:48.323 回答
2
我发现SQLite是最好的选择。虽然，我使用的是 nHibernate，但它是零配置，所以只需要一秒钟的时间来设置。但是，您必须意识到这些类型的引擎通常缺少您可能需要的一些东西（例如，如果您使用 ADO 提供程序，当您在表名中有空格时，SQLite 会爆炸）
当然，@TopBanana 关于不使用“实际”数据库的一些问题是正确的。然而，内存中的 RDBMS 非常适合那些想要快速运行的测试（例如，增量或 CI 构建的签入测试）。
另一个巨大的优势是您不必担心设置或拆卸。由于开发人员 A 破坏了您的开发数据库，因此您的签入失败是非常低效的；-)
于 2009-01-27T18:55:38.237 回答
1
SQL Server真的是单元测试的瓶颈吗？
我是说：
- 您是否分析了您的单元测试（使用 SQL Profiler 之类的工具）。他们都慢吗？有几个慢？为什么？
- 你的单元测试做得太多了吗？设置和拆卸代码是否过于繁重？
- 如果 SQL 是你的瓶颈，你是否考虑过一个模拟框架，所以你模拟出所有的 SQL 调用。
于 2009-01-27T11:39:04.390 回答
1
听说windows有挂载ramdisk的软件（不记得url了，不好意思）。
在此基础上创建测试数据库可能会很有趣。
于 2009-01-27T13:06:36.960 回答
1
我在使用 Oracle 时遇到了类似的挑战，我们做了以下事情：
确保我们有真正的单元测试没有触及数据库，而是使用模拟服务代替
实际需要 Oracle 的标记数据库测试与可以针对 HSQLDB 或 H2 或任何其他内存数据库运行的测试。所以我们可以单独运行它们。
在实际使用 Oracle 功能的测试中，我们使用了在 RAM 磁盘上运行的普通 Oracle 实例。
这使得测试相当快。
于 2011-11-18T14:18:48.590 回答
0
我建议您对单元测试使用与生产相同的数据库。当您调试实时问题时，您真的不需要一些奇怪的差异。
如果您查看 NHibernate 的非常大的单元测试套件，您会发现它使用 SQL Server（基于磁盘），并且测试运行得非常快。考虑到比一般的单元测试集要多得多的表创建/删除，这更令人印象深刻，这不是 SQL Server 优化的目标。
于 2009-01-27T11:41:54.603 回答