4

我有一个关于单元测试的问题。目前我有一个大型项目，它调用了许多 SP，并且大多数方法都没有得到回报。实际上，它是许多 SQL 调用的大型包装器。没有太多的逻辑，因为它全部保存在 SP 中，它也有部分行内 sql。

我需要对这个 c# 项目进行单元测试，但很明显，单元测试将毫无意义，因为它会调用许多 SP，所有这些都会被嘲笑。我是否担心我想错了。

我的问题是有人遇到过这个问题，他们做了什么？如果我改为进行数据库单元测试，任何见解都会有很大帮助。

谢谢。

4

4 回答 4

0

单元测试不应触及数据访问层，因为那将是集成测试/系统测试。您可以测试的是您的项目实际上调用了您的数据访问层。这样做会让您高枕无忧，因为在重构期间单击按钮总是会调用数据访问层。

//Arrange
var dataAccessMock = new Mock<IDataAccessMock>();
dataAccessMock(da => da.ExecuteSomething());

IYourApplication app = new YourApplication(dataAccessMock);

//Act
app.SomeProcessThatCallsExecuteSomething("1234567890");

/Assert
dataAccessMock.Verify(dp=>da.ExecuteSomething(), Times.Once());

请注意，在此示例中，我使用的是Moq

根据您的喜好对其进行测试后，您可以专注于集成测试，以验证您的存储过程是否按预期工作。为此，您可能需要做大量工作来附加处于已知状态的数据库，运行存储过程，然后恢复或丢弃您的数据库，以便可以重复测试。

于 2012-08-01T15:47:42.453 回答
0

您应该将测试策略拆分为集成测试和单元测试。

对于集成测试，您可以依赖现有的数据库。您通常会在这里编写更多高级测试并验证您的应用程序是否与数据库正确交互。

对于单元测试，您应该只选择对模拟有意义的选定场景。这些通常是很多业务逻辑“位于”数据库逻辑之上并且您想要验证该业务逻辑的场景。随着时间的推移，您可以模拟出越来越多的数据库调用，但首先要确定关键点。

于 2012-08-01T15:47:55.863 回答
0

您已经发现业务逻辑通常应该进入业务层而不是数据访问层的一个原因。当然，有性能和安全问题决定的例外，但它们应该仍然是例外。

话虽如此，您仍然可以开发一种策略来测试您的存储过程（尽管取决于它们的广泛程度，将这些测试称为“单元测试”可能是正确的，也可能是不正确的）。

无论哪种方式，您都可以使用单元测试框架。

在初始化部分，将数据库的测试副本恢复到已知状态，例如通过从先前保存的副本加载它。

然后，执行执行存储过程的单元测试。由于存储过程通常不返回任何内容，因此您的单元测试代码将不得不从数据库中选择值来检查是否进行了预期的更改。

根据存储过程之间可能的交互，可能有必要在每个测试之间或相关测试组之间恢复数据库。

于 2012-08-01T15:48:04.113 回答
0

从单元测试的角度来看，数据/持久层可能是最常被忽视的代码（使用测试替身的真正单元测试：模拟、存根、伪造等）。如果您要连接到数据库，那么您就是在进行集成测试。我在 a) 架构良好的数据/持久层中发现价值，作为副作用，易于测试（使用接口、良好的数据访问框架抽象等，b）实际上是单元和集成测试的属性。

于 2012-08-01T15:50:03.363 回答