用于单元测试的内存 DBMS
我正在寻找令人满意的选项来对我的 .NET DAL 类进行单元测试； 由于它们是 DAL 类，因此它们直接使用 ADO.NET 访问数据库。 目前，我使用 MSSQL 数据库的实例进行测试，但想知道有哪些更快的选项——由于单元测试需要尽可能快地运行，因此内存中的解决方案将是理想的选择。
我还应该提到，我已经将自己与 TSQL 联系在一起，因为我只会使用 Microsoft 平台。
I am looking for satisfactory options for unit testing my .NET DAL classes; since they're DAL classes, they access the database directly using ADO.NET. Presently I use an instance of a MSSQL database for the testing, but was wondering what faster options there are---since unit tests need to run as quickly as possible, an in-memory solution would be ideal.
I should also mention that I have tied myself to TSQL since I'm only ever going to be using a Microsoft platform.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
鉴于您声明：
那么使用 SqlServer 精简版可能会很好地满足您的需求。
它不会完全在内存中运行，但可以在只读模式下运行（主数据库文件不会发生任何编辑，因此可以一次用于多个测试）
有一些陷阱，不支持存储过程，一些数据类型需要转换，并且某些数据类型有严格的限制（特别是 varchar 只能达到 4000 个字符）Linq to Sql 也没有得到正确支持。
尽管如此，我还是使用了 SqlServer Compact Edition 作为适当 Sql Server 数据库的几乎完全替代品，并取得了良好的效果。
Given that you state:
Then Using SqlServer compact Edition may work well for your needs.
It will not operate entirely in memory but can operate in a readonly mode (where no edits occur to the main database file so it can be used by multiple tests at once)
There are a few gotchas, no stored procedures are supported, a few data types need to be translated and certain data types have tight limits (notably varchar which can only go to 4000 characters) Linq to Sql also is not properly supported.
Nonetheless I have used a SqlServer Compact Edition as an almost entirely drop replacement for the proper Sql Server database with good results.
我发现 SQLite 是最好的选择。 虽然我使用的是 nHibernate，但它是零配置，因此只需要一秒钟即可完成设置。 不过，您必须意识到这些类型的引擎通常缺少一些您可能需要的东西（例如，如果您使用 ADO 提供程序，当表名中有空格时，SQLite 就会崩溃）
当然，@TopBanana 是对的关于不使用“实际”数据库的一些问题。 然而，内存中的 RDBMS 非常适合您想要快速运行的测试（例如增量或 CI 构建的签入测试）。
另一个巨大的优势是您不必担心安装或拆卸。 由于开发人员 A 破坏了您的开发数据库而使您的签入失败，这是非常低效的;-)
I've found SQLite to be the best option. Though, I'm using nHibernate, but it's zero config so it only takes a sec to set up. Though, you do have to be aware that these types of engines typically lack a few things you might need (for example, SQLite blows up when you have spaces in table names if you're using an ADO provider)
Granted, @TopBanana is right about some of the issues with not using an "actual" database. However, an in-memory RDBMS is perfect for those kinds of tests you want to run really quickly (e.g. check-in tests for incremental or CI builds).
The other huge advantage is that you don't have to worry about setup or tear down. It's incredibly unproductive to have your check-in fail because developer A broke your dev database ;-)
我听说Windows中有安装ramdisk的软件（不记得url了，抱歉）。
在此基础上创建测试数据库可能会很有趣。
I heard that there is software to mount ramdisk in windows (can't remember url, sorry).
It could be interesting to create test databases on that.
SQL Server 真的是单元测试的瓶颈吗？
我的意思是：
Is SQL Server really the bottleneck for your unit tests?
I mean:
我在 Oracle 方面遇到了类似的挑战，我们做了以下工作：
确保我们进行真正的单元测试不会触及数据库，而是对服务使用模拟
标记的数据库测试实际上需要Oracle，而不是可以针对HSQLDB或H2或任何其他内存数据库运行的测试。 因此我们可以单独运行它们。
在实际使用 Oracle 功能的测试中，我们使用了在 RAM 磁盘上运行的普通 Oracle 实例。
这使得测试速度相当快。
I had similar challenges with Oracle and we did the following:
made sure that we had that real unit tests didn't touch the db, but used mocks for services instead
Tagged DB tests that actually needed Oracle versus the tests that could run against HSQLDB or H2 or any other in memory database. So we can run them separately.
With the tests that actually used Oracle features we used a normal Oracle instance that ran on a RAM disc.
This made the tests considerable faster.
我建议您在单元测试中使用与生产相同的数据库。 当你调试实时问题时，你真的不需要一些奇怪的差异来搬起石头砸自己的脚。
如果您查看 NHibernate 的真正大型单元测试套件，您会发现它使用 SQL Server（基于磁盘），并且测试运行得非常快。 更令人印象深刻的是，与平均单元测试集相比，进行的表创建/删除要多得多，而这并不是 SQL Server 优化的目的。
I would recommend using the same database for your unit tests as for production. You really don't need some weird difference shooting you in the foot when you're debugging a live issue.
If you have a look at the really big unit test suite for NHibernate, you'll see that it uses SQL Server (disk based), and the tests run surprisingly quickly. It's even more impressive consider that there's a lot more table creation / deletion going on than the average set of unit tests, which isn't what SQL Server is optimized for.