针对真实数据库对域服务进行单元测试

例如,一旦运行了测试,“创建”方面就已经运行了。再次运行它们显然会导致失败,因为数据库不再是原始的。

您可以使用 SQL Server Express (我在2005年做过,但在2008年没有尝试过)建立以文件形式存储的“测试平台”数据库。这些可以签入到源代码管理中,然后测试助手类可以(a)将它们复制到临时文件夹中,(b)启用写入,以及(c)连接到它们。要恢复原始状态,请删除临时副本并重复a-c。

This is a huge pain. 如果你能完成交易(正如杜菲莫建议的那样),我会同意的。事务的痛点是嵌套事务和分布式事务——注意代码中的那些。

为了更容易,将所有测试类子类化,并将事务访问器和回滚代码放在其中。回滚代码可以设置为在每个测试方法完成时自动运行。

如果您实际上正在为访问数据库的存储库执行单元测试,那么您并没有在进行单元测试。这可能是一个有用的测试,但它不是一个单元测试。这是一个整合测试。如果你想这样做并称之为集成测试,那么这是完全可以的。但是,如果您在存储库中遵循了良好的设计原则,那么您就不需要在单元测试中测试数据库。

很简单,您的存储库单元测试不是测试基于存储库输入的数据库中发生的广泛影响;它是为了确认对存储库的输入导致对具有这样一组值的合作者的调用。

你看,存储库和你的其他代码一样,应该遵循单一可存储性原则。基本上,您的职责只有一个可重复性,即将域模型API关注点传递到底层数据访问技术层(通常是ADO.Net,但可能是实体框架或L2S或其他)。以ADO为例。Net调用时,您的存储库不应承担数据层工厂的责任,而应依赖ADO中的协作者。网络数据接口(特别是IDbConnection/IDbCommand/IDbParameter等)。只需将IDbConnection作为构造函数参数并将其调用一天。这意味着您可以针对接口编写存储库单元测试,并提供模拟(或伪造、存根或任何您需要的),并确认所需的方法已按顺序进行,并具有预期的输入。请查看我的微软博客,了解这个确切的主题。> Link

希望这能帮助你在未来的测试和设计中避免犯错。

顺便说一句:如果你想对数据库进行单元测试,你可以。只需使用Visual Studio数据库测试。它内置了INTO vs,自VS2005以来一直存在。这不是什么新鲜事。但我需要提醒你,它们需要完全独立的单元测试。