我想知道其他人可能有什么方法来针对数据库测试域服务？我已经有了一系列的模拟存储库，我可以在域服务中使用这些存储库来测试域服务本身。这些模拟存储库的部分构造是它们构建出示例聚合和关联实体，并根据模型中使用的相同业务规则来验证它们。这还提供了一种很好且简单的方法，用于在实体的接口发生更改时检测实体本身内的潜在影响点。
我看到的对SQL支持的存储库进行实时测试的主要问题是数据库一致性。例如，一旦测试运行，“创建”方面已经运行。再次运行它们显然会导致失败，因为数据库不再是原始的。我正在考虑创建一个镜像数据库，仅用于这种类型的测试。它将是最小的，包含结构、可编程性、约束、我还将为某些已建立的测试提供一个最小的数据集。我的思路是，我可以有一个存储过程，我可以调用它来在测试运行开始之前用基本数据将数据库重置为“原始”状态。
虽然在功能已经初步验证之后，这在开发人员的机器上并不重要，但是我更关注将这些测试作为夜间构建的一部分来运行的重要性;以便在测试失败的情况下，构建可以被阻止，从而不污染目标部署环境（特别是在这种情况下，它将是测试团队使用的环境）。
我不一定认为平台很重要，但如果有人对实现有特定的顾虑，我的环境如下所示：
windows 7（开发）/ windows Server 2008 R2（服务器端）Visual Studio 2008团队版（C#）微软SQL Server 2008标准版（开发/服务器端）
我正在使用Team Build来运行我的构建，但这很可能不是问题范围内的一个因素。
5条答案
按热度按时间w7t8yxp51#
例如，一旦运行了一个测试，“创建”方面就已经运行过了，再次运行它们显然会导致失败，因为数据库不再是原始的。
也许你可以让你的单元测试事务化。运行你的测试，回滚它们，数据库就不会改变。
Spring有事务性单元测试类，可以使这一点变得很容易，您只需要一个事务管理器。
njthzxwz2#
你可以使用SQL Server Express（我在2005中做过，但在2008中没有尝试过）来设置存储为文件的“test deck”数据库。这些数据库可以签入到源代码管理中，然后测试助手类可以（a）将它们复制到临时文件夹，（b）使它们写，以及（c）连接到它们。要恢复原始状态，请删除临时副本并重复a-c。
This is a huge pain.如果你能应付事务（如duffymo所建议的），我会同意的。事务的难点是嵌套事务和分布式事务--在你的代码中要小心它们。
9lowa7mx3#
您可以在测试代码中创建一组数据工厂，这些数据工厂最初在测试运行启动时运行。然后使用事务回滚方法使其保持原始状态。为了使其更简单，请将所有测试类子类化，并将事务访问器和回滚代码放入其中。回滚代码可以设置为在每个测试方法完成时自动运行。
zbdgwd5y4#
如果你实际上是在为你的存储库执行单元测试，而这个单元测试正在访问一个数据库，那么你就不是在做单元测试。它可能是一个有用的测试，但它不是一个单元测试。那是一个集成测试。如果你想这样做，并称之为集成测试，那么这是非常好的。然而，如果你在你的存储库中遵循了好的设计原则，那么你就不需要测试数据库，永远，在单元测试中。
很简单，您的存储库单元测试不是基于存储库的输入测试数据库中发生了哪些广泛的影响;要确认对储存库的输入导致对具有这样或这样的一组值的合作者的调用。
您可以看到，存储库和您的其他代码一样，应该遵循单一可靠性原则，基本上，您的存储库有且只有一个可靠性，这就是将域模型API关注点传递到底层数据访问技术层（通常是ADO .NET，但也可以是实体框架或L2 S或其他）。以ADO .NET调用为例，您的存储库不应承担作为数据层工厂的责任，而应依赖于ADO .NET数据接口的协作者（具体来说是IDbConnection/IDbCommand/IDbParameter等）。只需将IDbConnection作为构造函数参数并调用它。这意味着您可以针对接口编写存储库单元测试，并提供模拟（或fakes或stub或您需要的任何东西），然后确认所需的方法是否按顺序生成，是否具有预期的输入。
希望这能帮助您在将来的测试和设计中避免犯错误。
顺便说一句：如果你想对数据库进行单元测试，你可以。只要使用Visual Studio数据库测试。它内置于VS中，从VS 2005开始就存在了。这并不是什么新鲜事。但我需要提醒你，它们需要是完全独立的单元测试。
ymdaylpp5#
如果您的代码是完全独立于数据库的，那么使用内存中的数据库（如SQLite）进行单元测试（而不是集成测试）将为您带来速度和易用性的好处（您的测试设置初始化db）。